* Re: [RFC] dt-bindings: net: phy: Add subnode for LED configuration
From: Andrew Lunn @ 2019-07-24 18:04 UTC (permalink / raw)
To: Matthias Kaehlcke
Cc: David S . Miller, Rob Herring, Mark Rutland, Florian Fainelli,
Heiner Kallweit, netdev, devicetree, linux-kernel,
Douglas Anderson
In-Reply-To: <20190722223741.113347-1-mka@chromium.org>
On Mon, Jul 22, 2019 at 03:37:41PM -0700, Matthias Kaehlcke wrote:
> The LED behavior of some Ethernet PHYs is configurable. Add an
> optional 'leds' subnode with a child node for each LED to be
> configured. The binding aims to be compatible with the common
> LED binding (see devicetree/bindings/leds/common.txt).
>
> A LED can be configured to be 'on' when a link with a certain speed
> is active, or to blink on RX/TX activity. For the configuration to
> be effective it needs to be supported by the hardware and the
> corresponding PHY driver.
>
> Suggested-by: Andrew Lunn <andrew@lunn.ch>
> Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
> ---
> This RFC is a follow up of the discussion on "[PATCH v2 6/7]
> dt-bindings: net: realtek: Add property to configure LED mode"
> (https://lore.kernel.org/patchwork/patch/1097185/).
>
> For now posting as RFC to get a basic agreement on the bindings
> before proceding with the implementation in phylib and a specific
> driver.
> ---
> Documentation/devicetree/bindings/net/phy.txt | 33 +++++++++++++++++++
> 1 file changed, 33 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/net/phy.txt b/Documentation/devicetree/bindings/net/phy.txt
> index 9b9e5b1765dd..ad495d3abbbb 100644
> --- a/Documentation/devicetree/bindings/net/phy.txt
> +++ b/Documentation/devicetree/bindings/net/phy.txt
> @@ -46,6 +46,25 @@ Optional Properties:
> Mark the corresponding energy efficient ethernet mode as broken and
> request the ethernet to stop advertising it.
>
> +- leds: A sub-node which is a container of only LED nodes. Each child
> + node represents a PHY LED.
> +
> + Required properties for LED child nodes:
> + - reg: The ID number of the LED, typically corresponds to a hardware ID.
> +
> + Optional properties for child nodes:
> + - label: The label for this LED. If omitted, the label is taken from the node
> + name (excluding the unit address). It has to uniquely identify a device,
> + i.e. no other LED class device can be assigned the same label.
Hi Matthias
I've thought about label a bit more.
> + label = "ethphy0:left:green";
We need to be careful with names here. systemd etc renames
interfaces. ethphy0 could in fact be connected to enp3s0, or eth0
might get renamed to eth1, etc. So i think we should avoid things like
ethphy0. Also, i'm not sure we actually need a label, at least not to
start with.Do we have any way to expose it to the user?
If we do ever make it part of the generic LED framework, we can then
use the label. At that point, i would probably combine the label with
the interface name in a dynamic way to avoid issues like this.
Andrew
^ permalink raw reply
* Re: Reminder: 99 open syzbot bugs in net subsystem
From: David Miller @ 2019-07-24 18:12 UTC (permalink / raw)
To: ebiggers
Cc: eric.dumazet, dvyukov, netdev, fw, i.maximets, edumazet, dsahern,
linux-kernel, syzkaller-bugs
In-Reply-To: <20190724163014.GC673@sol.localdomain>
From: Eric Biggers <ebiggers@kernel.org>
Date: Wed, 24 Jul 2019 09:30:14 -0700
> On Wed, Jul 24, 2019 at 08:39:05AM +0200, Eric Dumazet wrote:
>> Some of the bugs have been fixed already, before syzbot found them.
>>
>> Why force human to be gentle to bots and actually replying to them ?
>>
>> I usually simply wait that syzbot is finding the bug does not repro anymore,
>> but now if you send these emails, we will have even more pressure on us.
>>
>
> First, based on experience, I'd guess about 30-45 of these are still valid. 17
> were seen in mainline in the last week, but some others are valid too. The ones
> most likely to still be valid are at the beginning of the list. So let's try
> not use the presence of outdated bugs as an excuse not to fix current bugs.
So about half of the bugs we are to look at are already fixed and thus
noise, even as estimated by you.
I agree with Eric, these "reminders" are bad for the people you
actually want to work on fixing these bugs.
> Since the kernel community is basically in continuous bug bankruptcy and lots of
I don't like this hyperbole. Please present facts and information we
can actually use to improve the kernel development and bug fixing
process.
Thank you.
^ permalink raw reply
* Re: [PATCH net-next v2 0/8] Use dev_get_drvdata where possible
From: David Miller @ 2019-07-24 18:14 UTC (permalink / raw)
To: hslester96
Cc: klassert, jcliburn, chris.snook, rmody, michael.chan, siva.kallam,
prashant, GR-Linux-NIC-Dev, jeffrey.t.kirsher, cooldavid,
intel-wired-lan, netdev, linux-kernel
In-Reply-To: <20190724060512.23899-1-hslester96@gmail.com>
From: Chuhong Yuan <hslester96@gmail.com>
Date: Wed, 24 Jul 2019 14:05:12 +0800
> These patches use dev_get_drvdata instead of
> using to_pci_dev + pci_get_drvdata to make
> code simpler where possible.
>
> Changelog:
>
> v1 -> v2:
> - Change pci_set_drvdata to dev_set_drvdata
> to keep consistency.
Some of these patches were applied yesterday, weren't they?
Please take that into consideration when you repost, especially
when the maintainer(s) explicitly reply to your patches saying
"Applied." or similar like I always do.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next 04/11] net: hns3: fix mis-counting IRQ vector numbers issue
From: Saeed Mahameed @ 2019-07-24 18:28 UTC (permalink / raw)
To: tanhuazhong@huawei.com, davem@davemloft.net
Cc: lipeng321@huawei.com, yisen.zhuang@huawei.com,
salil.mehta@huawei.com, linuxarm@huawei.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
liuyonglong@huawei.com
In-Reply-To: <1563938327-9865-5-git-send-email-tanhuazhong@huawei.com>
On Wed, 2019-07-24 at 11:18 +0800, Huazhong Tan wrote:
> From: Yonglong Liu <liuyonglong@huawei.com>
>
> The num_msi_left means the vector numbers of NIC, but if the
> PF supported RoCE, it contains the vector numbers of NIC and
> RoCE(Not expected).
>
> This may cause interrupts lost in some case, because of the
> NIC module used the vector resources which belongs to RoCE.
>
> This patch corrects the value of num_msi_left to be equals to
> the vector numbers of NIC, and adjust the default tqp numbers
> according to the value of num_msi_left.
>
> Fixes: 46a3df9f9718 ("net: hns3: Add HNS3 Acceleration Engine &
> Compatibility Layer Support")
> Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
> Signed-off-by: Peng Li <lipeng321@huawei.com>
> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
> ---
> drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 5 ++++-
> drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_main.c | 12
> ++++++++++--
> 2 files changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
> b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
> index 3c64d70..a59d13f 100644
> --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
> +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
> @@ -1470,13 +1470,16 @@ static int hclge_vport_setup(struct
> hclge_vport *vport, u16 num_tqps)
> {
> struct hnae3_handle *nic = &vport->nic;
> struct hclge_dev *hdev = vport->back;
> + u16 alloc_tqps;
> int ret;
>
> nic->pdev = hdev->pdev;
> nic->ae_algo = &ae_algo;
> nic->numa_node_mask = hdev->numa_node_mask;
>
> - ret = hclge_knic_setup(vport, num_tqps,
> + alloc_tqps = min_t(u16, hdev->roce_base_msix_offset - 1,
Why do you need the extra alloc_tqps ? just overwrite num_tqps, the
original value is not needed afterwards.
> num_tqps);
> +
> + ret = hclge_knic_setup(vport, alloc_tqps,
> hdev->num_tx_desc, hdev->num_rx_desc);
> if (ret)
> dev_err(&hdev->pdev->dev, "knic setup failed %d\n",
> ret);
>
^ permalink raw reply
* Re: [PATCH v3] drivers: net: xgene: Remove acpi_has_method() calls
From: David Miller @ 2019-07-24 18:30 UTC (permalink / raw)
To: skunberg.kelsey
Cc: iyappan, keyur, quan, netdev, linux-kernel, skhan,
linux-kernel-mentees
In-Reply-To: <20190724060659.105292-1-skunberg.kelsey@gmail.com>
From: Kelsey Skunberg <skunberg.kelsey@gmail.com>
Date: Wed, 24 Jul 2019 00:06:59 -0600
> acpi_evaluate_object will already return an error if the needed method
> does not exist. Remove unnecessary acpi_has_method() calls and check the
> returned acpi_status for failure instead.
>
> Signed-off-by: Kelsey Skunberg <skunberg.kelsey@gmail.com>
> ---
> Changes in v2:
> - Fixed white space warnings and errors
>
> Changes in v3:
> - Resolved build errors caused by missing bracket
Applied, will push out after build testing :)
^ permalink raw reply
* Re: [PATCH net-next 06/11] net: hns3: modify firmware version display format
From: Saeed Mahameed @ 2019-07-24 18:34 UTC (permalink / raw)
To: tanhuazhong@huawei.com, davem@davemloft.net
Cc: lipeng321@huawei.com, yisen.zhuang@huawei.com,
salil.mehta@huawei.com, linuxarm@huawei.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
moyufeng@huawei.com
In-Reply-To: <1563938327-9865-7-git-send-email-tanhuazhong@huawei.com>
On Wed, 2019-07-24 at 11:18 +0800, Huazhong Tan wrote:
> From: Yufeng Mo <moyufeng@huawei.com>
>
> This patch modifies firmware version display format in
> hclge(vf)_cmd_init() and hns3_get_drvinfo(). Also, adds
> some optimizations for firmware version display format.
>
> Signed-off-by: Yufeng Mo <moyufeng@huawei.com>
> Signed-off-by: Peng Li <lipeng321@huawei.com>
> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
> ---
> drivers/net/ethernet/hisilicon/hns3/hnae3.h | 9
> +++++++++
> drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 15
> +++++++++++++--
> drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c | 10
> +++++++++-
> drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c | 11
> +++++++++--
> 4 files changed, 40 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
> b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
> index 48c7b70..a4624db 100644
> --- a/drivers/net/ethernet/hisilicon/hns3/hnae3.h
> +++ b/drivers/net/ethernet/hisilicon/hns3/hnae3.h
> @@ -179,6 +179,15 @@ struct hnae3_vector_info {
> #define HNAE3_RING_GL_RX 0
> #define HNAE3_RING_GL_TX 1
>
> +#define HNAE3_FW_VERSION_BYTE3_SHIFT 24
> +#define HNAE3_FW_VERSION_BYTE3_MASK GENMASK(31, 24)
> +#define HNAE3_FW_VERSION_BYTE2_SHIFT 16
> +#define HNAE3_FW_VERSION_BYTE2_MASK GENMASK(23, 16)
> +#define HNAE3_FW_VERSION_BYTE1_SHIFT 8
> +#define HNAE3_FW_VERSION_BYTE1_MASK GENMASK(15, 8)
> +#define HNAE3_FW_VERSION_BYTE0_SHIFT 0
> +#define HNAE3_FW_VERSION_BYTE0_MASK GENMASK(7, 0)
> +
> struct hnae3_ring_chain_node {
> struct hnae3_ring_chain_node *next;
> u32 tqp_index;
> diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
> b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
> index 5bff98a..e71c92b 100644
> --- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
> +++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
> @@ -527,6 +527,7 @@ static void hns3_get_drvinfo(struct net_device
> *netdev,
> {
> struct hns3_nic_priv *priv = netdev_priv(netdev);
> struct hnae3_handle *h = priv->ae_handle;
> + u32 fw_version;
>
> if (!h->ae_algo->ops->get_fw_version) {
> netdev_err(netdev, "could not get fw version!\n");
> @@ -545,8 +546,18 @@ static void hns3_get_drvinfo(struct net_device
> *netdev,
> sizeof(drvinfo->bus_info));
> drvinfo->bus_info[ETHTOOL_BUSINFO_LEN - 1] = '\0';
>
> - snprintf(drvinfo->fw_version, sizeof(drvinfo->fw_version),
> "0x%08x",
> - priv->ae_handle->ae_algo->ops->get_fw_version(h));
> + fw_version = priv->ae_handle->ae_algo->ops->get_fw_version(h);
> +
> + snprintf(drvinfo->fw_version, sizeof(drvinfo->fw_version),
> + "%lu.%lu.%lu.%lu",
> + hnae3_get_field(fw_version,
> HNAE3_FW_VERSION_BYTE3_MASK,
> + HNAE3_FW_VERSION_BYTE3_SHIFT),
> + hnae3_get_field(fw_version,
> HNAE3_FW_VERSION_BYTE2_MASK,
> + HNAE3_FW_VERSION_BYTE2_SHIFT),
> + hnae3_get_field(fw_version,
> HNAE3_FW_VERSION_BYTE1_MASK,
> + HNAE3_FW_VERSION_BYTE1_SHIFT),
> + hnae3_get_field(fw_version,
> HNAE3_FW_VERSION_BYTE0_MASK,
> + HNAE3_FW_VERSION_BYTE0_SHIFT));
> }
>
> static u32 hns3_get_link(struct net_device *netdev)
> diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
> b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
> index 22f6acd..c2320bf 100644
> --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
> +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_cmd.c
> @@ -419,7 +419,15 @@ int hclge_cmd_init(struct hclge_dev *hdev)
> }
> hdev->fw_version = version;
>
> - dev_info(&hdev->pdev->dev, "The firmware version is %08x\n",
> version);
> + pr_info_once("The firmware version is %lu.%lu.%lu.%lu\n",
> + hnae3_get_field(version,
> HNAE3_FW_VERSION_BYTE3_MASK,
> + HNAE3_FW_VERSION_BYTE3_SHIFT),
> + hnae3_get_field(version,
> HNAE3_FW_VERSION_BYTE2_MASK,
> + HNAE3_FW_VERSION_BYTE2_SHIFT),
> + hnae3_get_field(version,
> HNAE3_FW_VERSION_BYTE1_MASK,
> + HNAE3_FW_VERSION_BYTE1_SHIFT),
> + hnae3_get_field(version,
> HNAE3_FW_VERSION_BYTE0_MASK,
> + HNAE3_FW_VERSION_BYTE0_SHIFT));
>
Device name/string will not be printed now, what happens if i have
multiple devices ? at least print the device name as it was before
> return 0;
>
> diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c
> b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c
> index 652b796..004125b 100644
> --- a/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c
> +++ b/drivers/net/ethernet/hisilicon/hns3/hns3vf/hclgevf_cmd.c
> @@ -405,8 +405,15 @@ int hclgevf_cmd_init(struct hclgevf_dev *hdev)
> }
> hdev->fw_version = version;
>
> - dev_info(&hdev->pdev->dev, "The firmware version is %08x\n",
> version);
> -
> + pr_info_once("The firmware version is %lu.%lu.%lu.%lu\n",
> + hnae3_get_field(version,
> HNAE3_FW_VERSION_BYTE3_MASK,
> + HNAE3_FW_VERSION_BYTE3_SHIFT),
> + hnae3_get_field(version,
> HNAE3_FW_VERSION_BYTE2_MASK,
> + HNAE3_FW_VERSION_BYTE2_SHIFT),
> + hnae3_get_field(version,
> HNAE3_FW_VERSION_BYTE1_MASK,
> + HNAE3_FW_VERSION_BYTE1_SHIFT),
> + hnae3_get_field(version,
> HNAE3_FW_VERSION_BYTE0_MASK,
> + HNAE3_FW_VERSION_BYTE0_SHIFT));
> return 0;
>
Same.
^ permalink raw reply
* Re: Reminder: 99 open syzbot bugs in net subsystem
From: Eric Biggers @ 2019-07-24 18:37 UTC (permalink / raw)
To: David Miller
Cc: eric.dumazet, dvyukov, netdev, fw, i.maximets, edumazet, dsahern,
linux-kernel, syzkaller-bugs
In-Reply-To: <20190724.111225.2257475150626507655.davem@davemloft.net>
On Wed, Jul 24, 2019 at 11:12:25AM -0700, David Miller wrote:
> From: Eric Biggers <ebiggers@kernel.org>
> Date: Wed, 24 Jul 2019 09:30:14 -0700
>
> > On Wed, Jul 24, 2019 at 08:39:05AM +0200, Eric Dumazet wrote:
> >> Some of the bugs have been fixed already, before syzbot found them.
> >>
> >> Why force human to be gentle to bots and actually replying to them ?
> >>
> >> I usually simply wait that syzbot is finding the bug does not repro anymore,
> >> but now if you send these emails, we will have even more pressure on us.
> >>
> >
> > First, based on experience, I'd guess about 30-45 of these are still valid. 17
> > were seen in mainline in the last week, but some others are valid too. The ones
> > most likely to still be valid are at the beginning of the list. So let's try
> > not use the presence of outdated bugs as an excuse not to fix current bugs.
>
> So about half of the bugs we are to look at are already fixed and thus
> noise, even as estimated by you.
>
> I agree with Eric, these "reminders" are bad for the people you
> actually want to work on fixing these bugs.
Well, the problem is that no one knows for sure which bugs are fixed and which
aren't. To be certain, a human needs to review each bug. A bot can only guess.
Note that the bugs in my reminders are already automatically prioritized by how
likely they are to still be valid, important, actionable. So one simply needs
to start at the beginning of the list if they want to focus on those types of
bugs. Isn't this helpful?
>
> > Since the kernel community is basically in continuous bug bankruptcy and lots of
>
> I don't like this hyperbole. Please present facts and information we
> can actually use to improve the kernel development and bug fixing
> process.
>
A huge number of valid open bugs are not being fixed, which is a fact. We can
argue about what words to use to describe this situation, but it doesn't change
the situation itself.
What is your proposed solution?
- Eric
^ permalink raw reply
* Re: pull-request: can-next 2019-07-24,pull-request: can-next 2019-07-24
From: David Miller @ 2019-07-24 18:39 UTC (permalink / raw)
To: mkl; +Cc: netdev, kernel, linux-can
In-Reply-To: <93540cba-184a-a9c5-f9d2-b1779a69a36f@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Wed, 24 Jul 2019 11:00:24 +0200
> this is a pull request for net-next/master consisting of 26 patches.
Pulled, thanks Marc.
^ permalink raw reply
* Re: [PATCH net-next 00/10] Use dev_get_drvdata where possible
From: David Miller @ 2019-07-24 18:42 UTC (permalink / raw)
To: kvalo
Cc: hslester96, mlindner, stephen, jirislaby, mickflemm, mcgrof,
sgruszka, ath9k-devel, merez, johannes.berg, emmanuel.grumbach,
luciano.coelho, amitkarwar, nishants, gbhat, huxinming820,
imitsyanko, avinashp, smatyukevich, pkshih, linuxwifi,
linux-net-drivers, ecree, mhabets, netdev, wil6210,
linux-wireless, linux-kernel
In-Reply-To: <87zhl3zlu1.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Wed, 24 Jul 2019 14:57:42 +0300
> Do note that wireless patches go to wireless-drivers-next, not net-next.
> But I assume Dave will ignore patches 5-10 and I can take them.
Yes, that is what I plan to do.
^ permalink raw reply
* Re: [PATCH net-next 1/4] sctp: check addr_size with sa_family_t size in __sctp_setsockopt_connectx
From: Neil Horman @ 2019-07-24 18:44 UTC (permalink / raw)
To: Marcelo Ricardo Leitner; +Cc: Xin Long, network dev, linux-sctp, davem
In-Reply-To: <20190724124907.GA8640@localhost.localdomain>
On Wed, Jul 24, 2019 at 09:49:07AM -0300, Marcelo Ricardo Leitner wrote:
> On Wed, Jul 24, 2019 at 09:36:50AM -0300, Marcelo Ricardo Leitner wrote:
> > On Wed, Jul 24, 2019 at 07:22:35AM -0400, Neil Horman wrote:
> > > On Wed, Jul 24, 2019 at 03:21:12PM +0800, Xin Long wrote:
> > > > On Tue, Jul 23, 2019 at 11:25 PM Neil Horman <nhorman@tuxdriver.com> wrote:
> > > > >
> > > > > On Tue, Jul 23, 2019 at 01:37:57AM +0800, Xin Long wrote:
> > > > > > Now __sctp_connect() is called by __sctp_setsockopt_connectx() and
> > > > > > sctp_inet_connect(), the latter has done addr_size check with size
> > > > > > of sa_family_t.
> > > > > >
> > > > > > In the next patch to clean up __sctp_connect(), we will remove
> > > > > > addr_size check with size of sa_family_t from __sctp_connect()
> > > > > > for the 1st address.
> > > > > >
> > > > > > So before doing that, __sctp_setsockopt_connectx() should do
> > > > > > this check first, as sctp_inet_connect() does.
> > > > > >
> > > > > > Signed-off-by: Xin Long <lucien.xin@gmail.com>
> > > > > > ---
> > > > > > net/sctp/socket.c | 2 +-
> > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> > > > > > index aa80cda..5f92e4a 100644
> > > > > > --- a/net/sctp/socket.c
> > > > > > +++ b/net/sctp/socket.c
> > > > > > @@ -1311,7 +1311,7 @@ static int __sctp_setsockopt_connectx(struct sock *sk,
> > > > > > pr_debug("%s: sk:%p addrs:%p addrs_size:%d\n",
> > > > > > __func__, sk, addrs, addrs_size);
> > > > > >
> > > > > > - if (unlikely(addrs_size <= 0))
> > > > > > + if (unlikely(addrs_size < sizeof(sa_family_t)))
> > > > > I don't think this is what you want to check for here. sa_family_t is
> > > > > an unsigned short, and addrs_size is the number of bytes in the addrs
> > > > > array. The addrs array should be at least the size of one struct
> > > > > sockaddr (16 bytes iirc), and, if larger, should be a multiple of
> > > > > sizeof(struct sockaddr)
> > > > sizeof(struct sockaddr) is not the right value to check either.
> > > >
> > > > The proper check will be done later in __sctp_connect():
> > > >
> > > > af = sctp_get_af_specific(daddr->sa.sa_family);
> > > > if (!af || af->sockaddr_len > addrs_size)
> > > > return -EINVAL;
> > > >
> > > > So the check 'addrs_size < sizeof(sa_family_t)' in this patch is
> > > > just to make sure daddr->sa.sa_family is accessible. the same
> > > > check is also done in sctp_inet_connect().
> > > >
> > > That doesn't make much sense, if the proper check is done in __sctp_connect with
> > > the size of the families sockaddr_len, then we don't need this check at all, we
> > > can just let memdup_user take the fault on copy_to_user and return -EFAULT. If
> > > we get that from memdup_user, we know its not accessible, and can bail out.
> > >
> > > About the only thing we need to check for here is that addr_len isn't some
> > > absurdly high value (i.e. a negative value), so that we avoid trying to kmalloc
> > > upwards of 2G in memdup_user. Your change does that just fine, but its no
> > > better or worse than checking for <=0
> >
> > One can argue that such check against absurdly high values is random
> > and not effective, as 2G can be somewhat reasonable on 8GB systems but
> > certainly isn't on 512MB ones. On that, kmemdup_user() will also fail
> > gracefully as it uses GFP_USER and __GFP_NOWARN.
> >
> > The original check is more for protecting for sane usage of the
> > variable, which is an int, and a negative value is questionable. We
> > could cast, yes, but.. was that really the intent of the application?
> > Probably not.
>
> Though that said, I'm okay with the new check here: a quick sanity
> check that can avoid expensive calls to kmalloc(), while more refined
> check is done later on.
>
I agree a sanity check makes sense, just to avoid allocating a huge value
(even 2G is absurd on many systems), however, I'm not super comfortable with
checking for the value being less than 16 (sizeof(sa_family_t)). The zero check
is fairly obvious given the signed nature of the lengh field, this check makes
me wonder what exactly we are checking for.
Neil
> >
> > >
> > > Neil
> > >
> > > > >
> > > > > Neil
> > > > >
> > > > > > return -EINVAL;
> > > > > >
> > > > > > kaddrs = memdup_user(addrs, addrs_size);
> > > > > > --
> > > > > > 2.1.0
> > > > > >
> > > > > >
> > > >
>
^ permalink raw reply
* Re: [PATCH net-next 00/10] Use dev_get_drvdata where possible
From: David Miller @ 2019-07-24 18:45 UTC (permalink / raw)
To: hslester96
Cc: mlindner, stephen, jirislaby, mickflemm, mcgrof, sgruszka, kvalo,
ath9k-devel, merez, johannes.berg, emmanuel.grumbach,
luciano.coelho, amitkarwar, nishants, gbhat, huxinming820,
imitsyanko, avinashp, smatyukevich, pkshih, linuxwifi,
linux-net-drivers, ecree, mhabets, netdev, wil6210,
linux-wireless, linux-kernel
In-Reply-To: <20190724112524.13042-1-hslester96@gmail.com>
From: Chuhong Yuan <hslester96@gmail.com>
Date: Wed, 24 Jul 2019 19:25:24 +0800
> These patches use dev_get_drvdata instead of
> using to_pci_dev + pci_get_drvdata to make
> code simpler.
Patches 1-4 applied to net-nex t.
^ permalink raw reply
* Re: [PATCH] Build fixes for skb_frag_size conversion
From: David Miller @ 2019-07-24 18:46 UTC (permalink / raw)
To: willy; +Cc: netdev
In-Reply-To: <20190724113615.11961-1-willy@infradead.org>
From: Matthew Wilcox <willy@infradead.org>
Date: Wed, 24 Jul 2019 04:36:15 -0700
> From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
>
> I missed a few places. One is in some ifdeffed code which will probably
> never be re-enabled; the others are in drivers which can't currently be
> compiled on x86.
>
> Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Applied, thanks for following up.
^ permalink raw reply
* Re: [PATCH v3 6/7] net: Rename skb_frag_t size to bv_len
From: David Miller @ 2019-07-24 18:46 UTC (permalink / raw)
To: willy; +Cc: David.Laight, hch, netdev
In-Reply-To: <20190724114120.GT363@bombadil.infradead.org>
From: Matthew Wilcox <willy@infradead.org>
Date: Wed, 24 Jul 2019 04:41:21 -0700
> On Wed, Jul 24, 2019 at 10:49:03AM +0000, David Laight wrote:
>> This is 'just plain stupid'.
>> The 'bv_' prefix of the members of 'struct bvec' is there so that 'grep'
>> (etc) can be used to find the uses of the members.
>>
>> In a 'struct skb_frag_struct' a sensible prefix might be 'sf_'.
>>
>> OTOH it might be sensible to use (or embed) a 'struct bvec'
>> instead of 'skb_frag_struct'.
>
> Maybe you should read patch 7/7. Or 0/7.
+1
^ permalink raw reply
* Re: [PATCH net-next 0/4] sctp: clean up __sctp_connect function
From: Neil Horman @ 2019-07-24 18:47 UTC (permalink / raw)
To: Marcelo Ricardo Leitner; +Cc: Xin Long, network dev, linux-sctp, davem
In-Reply-To: <20190724142512.GG6204@localhost.localdomain>
On Wed, Jul 24, 2019 at 11:25:12AM -0300, Marcelo Ricardo Leitner wrote:
> On Tue, Jul 23, 2019 at 01:37:56AM +0800, Xin Long wrote:
> > This patchset is to factor out some common code for
> > sctp_sendmsg_new_asoc() and __sctp_connect() into 2
> > new functioins.
> >
> > Xin Long (4):
> > sctp: check addr_size with sa_family_t size in
> > __sctp_setsockopt_connectx
> > sctp: clean up __sctp_connect
> > sctp: factor out sctp_connect_new_asoc
> > sctp: factor out sctp_connect_add_peer
>
> Nice cleanup! These patches LGTM. Hopefully for Neil as well.
>
> Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
>
Yes, agreed, this all looks good, but I would like to resolve the addr_length
check issue before I ack it.
Neil
^ permalink raw reply
* Re: [PATCH net-next v3 8/8] net: mscc: PTP Hardware Clock (PHC) support
From: David Miller @ 2019-07-24 18:52 UTC (permalink / raw)
To: antoine.tenart
Cc: richardcochran, alexandre.belloni, UNGLinuxDriver, ralf,
paul.burton, jhogan, netdev, linux-mips, thomas.petazzoni,
allan.nielsen
In-Reply-To: <20190724081715.29159-9-antoine.tenart@bootlin.com>
From: Antoine Tenart <antoine.tenart@bootlin.com>
Date: Wed, 24 Jul 2019 10:17:15 +0200
> +static int ocelot_ptp_adjfine(struct ptp_clock_info *ptp, long scaled_ppm)
> +{
> + struct ocelot *ocelot = container_of(ptp, struct ocelot, ptp_info);
> + u32 unit = 0, direction = 0;
> + unsigned long flags;
^^^^
> + u64 adj = 0;
> +
> + if (!scaled_ppm)
> + goto disable_adj;
...
> +disable_adj:
> + ocelot_write(ocelot, 0, PTP_CLK_CFG_ADJ_CFG);
> +
> + spin_unlock_irqrestore(&ocelot->ptp_clock_lock, flags);
^^^^^
Did GCC really not warn about this in your build like it did immediately
on mine?
drivers/net/ethernet/mscc/ocelot.c: In function ‘ocelot_ptp_adjfine’:
./include/linux/spinlock.h:288:3: warning: ‘flags’ may be used uninitialized in this function [-Wmaybe-uninitialized]
_raw_spin_unlock_irqrestore(lock, flags); \
^~~~~~~~~~~~~~~~~~~~~~~~~~~
Please fix this and when you respin please just elide the MIPS tree
patches and just keep all the ones that I should apply to net-next.
Thank you.
^ permalink raw reply
* Re: Reminder: 99 open syzbot bugs in net subsystem
From: Eric Dumazet @ 2019-07-24 18:52 UTC (permalink / raw)
To: David Miller, Eric Dumazet, Dmitry Vyukov, netdev,
Florian Westphal, i.maximets, Eric Dumazet, David Ahern, LKML,
syzkaller-bugs
In-Reply-To: <20190724183710.GF213255@gmail.com>
On Wed, Jul 24, 2019 at 8:37 PM Eric Biggers <ebiggers@kernel.org> wrote:
> A huge number of valid open bugs are not being fixed, which is a fact. We can
> argue about what words to use to describe this situation, but it doesn't change
> the situation itself.
>
> What is your proposed solution?
syzbot sends emails, plenty of them, with many wrong bisection
results, increasing the noise.
If nobody is interested, I am not sure sending copies of them
repeatedly will be of any help.
Maybe a simple monthly reminder with one URL to go to the list of bugs
would be less intrusive.
^ permalink raw reply
* Re: Reminder: 99 open syzbot bugs in net subsystem
From: Eric Biggers @ 2019-07-24 19:03 UTC (permalink / raw)
To: Eric Dumazet
Cc: David Miller, Eric Dumazet, Dmitry Vyukov, netdev,
Florian Westphal, i.maximets, David Ahern, LKML, syzkaller-bugs
In-Reply-To: <CANn89iKZcdk-YfqZ-F1toHDLW3Etf5oPR78bXOq0FbjwWyiSMQ@mail.gmail.com>
On Wed, Jul 24, 2019 at 08:52:54PM +0200, 'Eric Dumazet' via syzkaller-bugs wrote:
> On Wed, Jul 24, 2019 at 8:37 PM Eric Biggers <ebiggers@kernel.org> wrote:
>
> > A huge number of valid open bugs are not being fixed, which is a fact. We can
> > argue about what words to use to describe this situation, but it doesn't change
> > the situation itself.
> >
> > What is your proposed solution?
>
> syzbot sends emails, plenty of them, with many wrong bisection
> results, increasing the noise.
>
> If nobody is interested, I am not sure sending copies of them
> repeatedly will be of any help.
>
> Maybe a simple monthly reminder with one URL to go to the list of bugs
> would be less intrusive.
>
The bogus bisection results is a known issue (which I'm trying to convince
Dmitry is important enough to fix...), which is why I manually reviewed all of
them and discarded out all the obviously incorrect ones. My reminders only
include manually reviewed bisection results. Obviously there will still be some
looked plausible but are actualy wrong, but I suspect the accuracy is around
80-90% rather than the 40-50% of the raw syzbot bisection results.
- Eric
^ permalink raw reply
* Re: [PATCH net-next 1/4] sctp: check addr_size with sa_family_t size in __sctp_setsockopt_connectx
From: Marcelo Ricardo Leitner @ 2019-07-24 19:05 UTC (permalink / raw)
To: Neil Horman; +Cc: Xin Long, network dev, linux-sctp, davem
In-Reply-To: <20190724184456.GC7212@hmswarspite.think-freely.org>
On Wed, Jul 24, 2019 at 02:44:56PM -0400, Neil Horman wrote:
> On Wed, Jul 24, 2019 at 09:49:07AM -0300, Marcelo Ricardo Leitner wrote:
> > On Wed, Jul 24, 2019 at 09:36:50AM -0300, Marcelo Ricardo Leitner wrote:
> > > On Wed, Jul 24, 2019 at 07:22:35AM -0400, Neil Horman wrote:
> > > > On Wed, Jul 24, 2019 at 03:21:12PM +0800, Xin Long wrote:
> > > > > On Tue, Jul 23, 2019 at 11:25 PM Neil Horman <nhorman@tuxdriver.com> wrote:
> > > > > >
> > > > > > On Tue, Jul 23, 2019 at 01:37:57AM +0800, Xin Long wrote:
> > > > > > > Now __sctp_connect() is called by __sctp_setsockopt_connectx() and
> > > > > > > sctp_inet_connect(), the latter has done addr_size check with size
> > > > > > > of sa_family_t.
> > > > > > >
> > > > > > > In the next patch to clean up __sctp_connect(), we will remove
> > > > > > > addr_size check with size of sa_family_t from __sctp_connect()
> > > > > > > for the 1st address.
> > > > > > >
> > > > > > > So before doing that, __sctp_setsockopt_connectx() should do
> > > > > > > this check first, as sctp_inet_connect() does.
> > > > > > >
> > > > > > > Signed-off-by: Xin Long <lucien.xin@gmail.com>
> > > > > > > ---
> > > > > > > net/sctp/socket.c | 2 +-
> > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > >
> > > > > > > diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> > > > > > > index aa80cda..5f92e4a 100644
> > > > > > > --- a/net/sctp/socket.c
> > > > > > > +++ b/net/sctp/socket.c
> > > > > > > @@ -1311,7 +1311,7 @@ static int __sctp_setsockopt_connectx(struct sock *sk,
> > > > > > > pr_debug("%s: sk:%p addrs:%p addrs_size:%d\n",
> > > > > > > __func__, sk, addrs, addrs_size);
> > > > > > >
> > > > > > > - if (unlikely(addrs_size <= 0))
> > > > > > > + if (unlikely(addrs_size < sizeof(sa_family_t)))
> > > > > > I don't think this is what you want to check for here. sa_family_t is
> > > > > > an unsigned short, and addrs_size is the number of bytes in the addrs
> > > > > > array. The addrs array should be at least the size of one struct
> > > > > > sockaddr (16 bytes iirc), and, if larger, should be a multiple of
> > > > > > sizeof(struct sockaddr)
> > > > > sizeof(struct sockaddr) is not the right value to check either.
> > > > >
> > > > > The proper check will be done later in __sctp_connect():
> > > > >
> > > > > af = sctp_get_af_specific(daddr->sa.sa_family);
> > > > > if (!af || af->sockaddr_len > addrs_size)
> > > > > return -EINVAL;
> > > > >
> > > > > So the check 'addrs_size < sizeof(sa_family_t)' in this patch is
> > > > > just to make sure daddr->sa.sa_family is accessible. the same
> > > > > check is also done in sctp_inet_connect().
> > > > >
> > > > That doesn't make much sense, if the proper check is done in __sctp_connect with
> > > > the size of the families sockaddr_len, then we don't need this check at all, we
> > > > can just let memdup_user take the fault on copy_to_user and return -EFAULT. If
> > > > we get that from memdup_user, we know its not accessible, and can bail out.
> > > >
> > > > About the only thing we need to check for here is that addr_len isn't some
> > > > absurdly high value (i.e. a negative value), so that we avoid trying to kmalloc
> > > > upwards of 2G in memdup_user. Your change does that just fine, but its no
> > > > better or worse than checking for <=0
> > >
> > > One can argue that such check against absurdly high values is random
> > > and not effective, as 2G can be somewhat reasonable on 8GB systems but
> > > certainly isn't on 512MB ones. On that, kmemdup_user() will also fail
> > > gracefully as it uses GFP_USER and __GFP_NOWARN.
> > >
> > > The original check is more for protecting for sane usage of the
> > > variable, which is an int, and a negative value is questionable. We
> > > could cast, yes, but.. was that really the intent of the application?
> > > Probably not.
> >
> > Though that said, I'm okay with the new check here: a quick sanity
> > check that can avoid expensive calls to kmalloc(), while more refined
> > check is done later on.
> >
> I agree a sanity check makes sense, just to avoid allocating a huge value
> (even 2G is absurd on many systems), however, I'm not super comfortable with
> checking for the value being less than 16 (sizeof(sa_family_t)). The zero check
16 bits you mean then, per
include/uapi/linux/socket.h
typedef unsigned short __kernel_sa_family_t;
include/linux/socket.h
typedef __kernel_sa_family_t sa_family_t;
> is fairly obvious given the signed nature of the lengh field, this check makes
> me wonder what exactly we are checking for.
A minimum viable buffer without doing more extensive tests. Beyond
sa_family, we need to parse sa_family and then that's left for later.
Perhaps a comment helps, something like
/* Check if we have at least the family type in there */
?
Marcelo
>
> Neil
>
> > >
> > > >
> > > > Neil
> > > >
> > > > > >
> > > > > > Neil
> > > > > >
> > > > > > > return -EINVAL;
> > > > > > >
> > > > > > > kaddrs = memdup_user(addrs, addrs_size);
> > > > > > > --
> > > > > > > 2.1.0
> > > > > > >
> > > > > > >
> > > > >
> >
^ permalink raw reply
* Re: [PATCH net-next 07/11] net: hns3: adds debug messages to identify eth down cause
From: Saeed Mahameed @ 2019-07-24 19:12 UTC (permalink / raw)
To: tanhuazhong@huawei.com, davem@davemloft.net
Cc: lipeng321@huawei.com, yisen.zhuang@huawei.com,
salil.mehta@huawei.com, linuxarm@huawei.com,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
liuyonglong@huawei.com
In-Reply-To: <1563938327-9865-8-git-send-email-tanhuazhong@huawei.com>
On Wed, 2019-07-24 at 11:18 +0800, Huazhong Tan wrote:
> From: Yonglong Liu <liuyonglong@huawei.com>
>
> Some times just see the eth interface have been down/up via
> dmesg, but can not know why the eth down. So adds some debug
> messages to identify the cause for this.
>
I really don't like this. your default msg lvl has NETIF_MSG_IFDOWN
turned on .. dumping every single operation that happens on your device
by default to kernel log is too much !
We should really consider using trace buffers with well defined
structures for vendor specific events. so we can use bpf filters and
state of the art tools for netdev debugging.
> Signed-off-by: Yonglong Liu <liuyonglong@huawei.com>
> Signed-off-by: Peng Li <lipeng321@huawei.com>
> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
> ---
> drivers/net/ethernet/hisilicon/hns3/hns3_enet.c | 24
> ++++++++++++++++++++
> drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c | 26
> ++++++++++++++++++++++
> .../net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c | 14 ++++++++++++
> 3 files changed, 64 insertions(+)
>
> diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
> b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
> index 4d58c53..cff5d59 100644
> --- a/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
> +++ b/drivers/net/ethernet/hisilicon/hns3/hns3_enet.c
> @@ -459,6 +459,10 @@ static int hns3_nic_net_open(struct net_device
> *netdev)
> h->ae_algo->ops->set_timer_task(priv->ae_handle, true);
>
> hns3_config_xps(priv);
> +
> + if (netif_msg_ifup(h))
> + netdev_info(netdev, "net open\n");
> +
> return 0;
> }
>
> @@ -519,6 +523,9 @@ static int hns3_nic_net_stop(struct net_device
> *netdev)
> if (test_and_set_bit(HNS3_NIC_STATE_DOWN, &priv->state))
> return 0;
>
> + if (netif_msg_ifdown(h))
> + netdev_info(netdev, "net stop\n");
> +
> if (h->ae_algo->ops->set_timer_task)
> h->ae_algo->ops->set_timer_task(priv->ae_handle,
> false);
>
> @@ -1550,6 +1557,9 @@ static int hns3_setup_tc(struct net_device
> *netdev, void *type_data)
> h = hns3_get_handle(netdev);
> kinfo = &h->kinfo;
>
> + if (netif_msg_ifdown(h))
> + netdev_info(netdev, "setup tc: num_tc=%d\n", tc);
> +
> return (kinfo->dcb_ops && kinfo->dcb_ops->setup_tc) ?
> kinfo->dcb_ops->setup_tc(h, tc, prio_tc) : -EOPNOTSUPP;
> }
> @@ -1593,6 +1603,11 @@ static int hns3_ndo_set_vf_vlan(struct
> net_device *netdev, int vf, u16 vlan,
> struct hnae3_handle *h = hns3_get_handle(netdev);
> int ret = -EIO;
>
> + if (netif_msg_ifdown(h))
why msg_ifdown ? looks like netif_msg_drv is more appropriate, for many
of the cases in this patch.
> + netdev_info(netdev,
> + "set vf vlan: vf=%d, vlan=%d, qos=%d,
> vlan_proto=%d\n",
> + vf, vlan, qos, vlan_proto);
> +
> if (h->ae_algo->ops->set_vf_vlan_filter)
> ret = h->ae_algo->ops->set_vf_vlan_filter(h, vf, vlan,
> qos,
> vlan_proto);
> @@ -1611,6 +1626,10 @@ static int hns3_nic_change_mtu(struct
> net_device *netdev, int new_mtu)
> if (!h->ae_algo->ops->set_mtu)
> return -EOPNOTSUPP;
>
> + if (netif_msg_ifdown(h))
> + netdev_info(netdev, "change mtu from %d to %d\n",
> + netdev->mtu, new_mtu);
> +
> ret = h->ae_algo->ops->set_mtu(h, new_mtu);
> if (ret)
> netdev_err(netdev, "failed to change MTU in hardware
> %d\n",
> @@ -4395,6 +4414,11 @@ int hns3_set_channels(struct net_device
> *netdev,
> if (kinfo->rss_size == new_tqp_num)
> return 0;
>
> + if (netif_msg_ifdown(h))
> + netdev_info(netdev,
> + "set channels: tqp_num=%d, rxfh=%d\n",
> + new_tqp_num, rxfh_configured);
> +
> ret = hns3_reset_notify(h, HNAE3_DOWN_CLIENT);
> if (ret)
> return ret;
> diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
> b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
> index e71c92b..edb9845 100644
> --- a/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
> +++ b/drivers/net/ethernet/hisilicon/hns3/hns3_ethtool.c
> @@ -311,6 +311,9 @@ static void hns3_self_test(struct net_device
> *ndev,
> if (eth_test->flags != ETH_TEST_FL_OFFLINE)
> return;
>
> + if (netif_msg_ifdown(h))
> + netdev_info(ndev, "self test start\n");
> +
> st_param[HNAE3_LOOP_APP][0] = HNAE3_LOOP_APP;
> st_param[HNAE3_LOOP_APP][1] =
> h->flags & HNAE3_SUPPORT_APP_LOOPBACK;
> @@ -374,6 +377,9 @@ static void hns3_self_test(struct net_device
> *ndev,
>
> if (if_running)
> ndev->netdev_ops->ndo_open(ndev);
> +
> + if (netif_msg_ifdown(h))
> + netdev_info(ndev, "self test end\n");
> }
>
> static int hns3_get_sset_count(struct net_device *netdev, int
> stringset)
> @@ -604,6 +610,11 @@ static int hns3_set_pauseparam(struct net_device
> *netdev,
> {
> struct hnae3_handle *h = hns3_get_handle(netdev);
>
> + if (netif_msg_ifdown(h))
> + netdev_info(netdev,
> + "set pauseparam: autoneg=%d, rx:%d,
> tx:%d\n",
> + param->autoneg, param->rx_pause, param-
> >tx_pause);
> +
> if (h->ae_algo->ops->set_pauseparam)
> return h->ae_algo->ops->set_pauseparam(h, param-
> >autoneg,
> param->rx_pause,
> @@ -743,6 +754,13 @@ static int hns3_set_link_ksettings(struct
> net_device *netdev,
> if (cmd->base.speed == SPEED_1000 && cmd->base.duplex ==
> DUPLEX_HALF)
> return -EINVAL;
>
> + if (netif_msg_ifdown(handle))
> + netdev_info(netdev,
> + "set link(%s): autoneg=%d, speed=%d,
> duplex=%d\n",
> + netdev->phydev ? "phy" : "mac",
> + cmd->base.autoneg, cmd->base.speed,
> + cmd->base.duplex);
> +
> /* Only support ksettings_set for netdev with phy attached for
> now */
> if (netdev->phydev)
> return phy_ethtool_ksettings_set(netdev->phydev, cmd);
> @@ -984,6 +1002,10 @@ static int hns3_nway_reset(struct net_device
> *netdev)
> return -EINVAL;
> }
>
> + if (netif_msg_ifdown(handle))
> + netdev_info(netdev, "nway reset (using %s)\n",
> + phy ? "phy" : "mac");
> +
> if (phy)
> return genphy_restart_aneg(phy);
>
> @@ -1308,6 +1330,10 @@ static int hns3_set_fecparam(struct net_device
> *netdev,
> if (!ops->set_fec)
> return -EOPNOTSUPP;
> fec_mode = eth_to_loc_fec(fec->fec);
> +
> + if (netif_msg_ifdown(handle))
> + netdev_info(netdev, "set fecparam: mode=%d\n",
> fec_mode);
> +
> return ops->set_fec(handle, fec_mode);
> }
>
> diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
> b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
> index bac4ce1..133e7c6 100644
> --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
> +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_dcb.c
> @@ -201,6 +201,7 @@ static int hclge_client_setup_tc(struct hclge_dev
> *hdev)
> static int hclge_ieee_setets(struct hnae3_handle *h, struct ieee_ets
> *ets)
> {
> struct hclge_vport *vport = hclge_get_vport(h);
> + struct net_device *netdev = h->kinfo.netdev;
> struct hclge_dev *hdev = vport->back;
> bool map_changed = false;
> u8 num_tc = 0;
> @@ -215,6 +216,9 @@ static int hclge_ieee_setets(struct hnae3_handle
> *h, struct ieee_ets *ets)
> return ret;
>
> if (map_changed) {
> + if (netif_msg_ifdown(h))
> + netdev_info(netdev, "set ets\n");
> +
> ret = hclge_notify_client(hdev, HNAE3_DOWN_CLIENT);
> if (ret)
> return ret;
> @@ -300,6 +304,7 @@ static int hclge_ieee_getpfc(struct hnae3_handle
> *h, struct ieee_pfc *pfc)
> static int hclge_ieee_setpfc(struct hnae3_handle *h, struct ieee_pfc
> *pfc)
> {
> struct hclge_vport *vport = hclge_get_vport(h);
> + struct net_device *netdev = h->kinfo.netdev;
> struct hclge_dev *hdev = vport->back;
> u8 i, j, pfc_map, *prio_tc;
>
> @@ -325,6 +330,11 @@ static int hclge_ieee_setpfc(struct hnae3_handle
> *h, struct ieee_pfc *pfc)
> hdev->tm_info.hw_pfc_map = pfc_map;
> hdev->tm_info.pfc_en = pfc->pfc_en;
>
> + if (netif_msg_ifdown(h))
> + netdev_info(netdev,
> + "set pfc: pfc_en=%d, pfc_map=%d,
> num_tc=%d\n",
> + pfc->pfc_en, pfc_map, hdev-
> >tm_info.num_tc);
> +
> hclge_tm_pfc_info_update(hdev);
>
> return hclge_pause_setup_hw(hdev, false);
> @@ -345,8 +355,12 @@ static u8 hclge_getdcbx(struct hnae3_handle *h)
> static u8 hclge_setdcbx(struct hnae3_handle *h, u8 mode)
> {
> struct hclge_vport *vport = hclge_get_vport(h);
> + struct net_device *netdev = h->kinfo.netdev;
> struct hclge_dev *hdev = vport->back;
>
> + if (netif_msg_drv(h))
> + netdev_info(netdev, "set dcbx: mode=%d\n", mode);
> +
> /* No support for LLD_MANAGED modes or CEE */
> if ((mode & DCB_CAP_DCBX_LLD_MANAGED) ||
> (mode & DCB_CAP_DCBX_VER_CEE) ||
^ permalink raw reply
* Re: [PATCH net-next 1/4] sctp: check addr_size with sa_family_t size in __sctp_setsockopt_connectx
From: Marcelo Ricardo Leitner @ 2019-07-24 19:12 UTC (permalink / raw)
To: Neil Horman; +Cc: Xin Long, network dev, linux-sctp, davem
In-Reply-To: <20190724190543.GH6204@localhost.localdomain>
On Wed, Jul 24, 2019 at 04:05:43PM -0300, Marcelo Ricardo Leitner wrote:
> On Wed, Jul 24, 2019 at 02:44:56PM -0400, Neil Horman wrote:
> > On Wed, Jul 24, 2019 at 09:49:07AM -0300, Marcelo Ricardo Leitner wrote:
> > > On Wed, Jul 24, 2019 at 09:36:50AM -0300, Marcelo Ricardo Leitner wrote:
> > > > On Wed, Jul 24, 2019 at 07:22:35AM -0400, Neil Horman wrote:
> > > > > On Wed, Jul 24, 2019 at 03:21:12PM +0800, Xin Long wrote:
> > > > > > On Tue, Jul 23, 2019 at 11:25 PM Neil Horman <nhorman@tuxdriver.com> wrote:
> > > > > > >
> > > > > > > On Tue, Jul 23, 2019 at 01:37:57AM +0800, Xin Long wrote:
> > > > > > > > Now __sctp_connect() is called by __sctp_setsockopt_connectx() and
> > > > > > > > sctp_inet_connect(), the latter has done addr_size check with size
> > > > > > > > of sa_family_t.
> > > > > > > >
> > > > > > > > In the next patch to clean up __sctp_connect(), we will remove
> > > > > > > > addr_size check with size of sa_family_t from __sctp_connect()
> > > > > > > > for the 1st address.
> > > > > > > >
> > > > > > > > So before doing that, __sctp_setsockopt_connectx() should do
> > > > > > > > this check first, as sctp_inet_connect() does.
> > > > > > > >
> > > > > > > > Signed-off-by: Xin Long <lucien.xin@gmail.com>
> > > > > > > > ---
> > > > > > > > net/sctp/socket.c | 2 +-
> > > > > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > > > > >
> > > > > > > > diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> > > > > > > > index aa80cda..5f92e4a 100644
> > > > > > > > --- a/net/sctp/socket.c
> > > > > > > > +++ b/net/sctp/socket.c
> > > > > > > > @@ -1311,7 +1311,7 @@ static int __sctp_setsockopt_connectx(struct sock *sk,
> > > > > > > > pr_debug("%s: sk:%p addrs:%p addrs_size:%d\n",
> > > > > > > > __func__, sk, addrs, addrs_size);
> > > > > > > >
> > > > > > > > - if (unlikely(addrs_size <= 0))
> > > > > > > > + if (unlikely(addrs_size < sizeof(sa_family_t)))
> > > > > > > I don't think this is what you want to check for here. sa_family_t is
> > > > > > > an unsigned short, and addrs_size is the number of bytes in the addrs
> > > > > > > array. The addrs array should be at least the size of one struct
> > > > > > > sockaddr (16 bytes iirc), and, if larger, should be a multiple of
> > > > > > > sizeof(struct sockaddr)
> > > > > > sizeof(struct sockaddr) is not the right value to check either.
> > > > > >
> > > > > > The proper check will be done later in __sctp_connect():
> > > > > >
> > > > > > af = sctp_get_af_specific(daddr->sa.sa_family);
> > > > > > if (!af || af->sockaddr_len > addrs_size)
> > > > > > return -EINVAL;
> > > > > >
> > > > > > So the check 'addrs_size < sizeof(sa_family_t)' in this patch is
> > > > > > just to make sure daddr->sa.sa_family is accessible. the same
> > > > > > check is also done in sctp_inet_connect().
> > > > > >
> > > > > That doesn't make much sense, if the proper check is done in __sctp_connect with
> > > > > the size of the families sockaddr_len, then we don't need this check at all, we
> > > > > can just let memdup_user take the fault on copy_to_user and return -EFAULT. If
> > > > > we get that from memdup_user, we know its not accessible, and can bail out.
> > > > >
> > > > > About the only thing we need to check for here is that addr_len isn't some
> > > > > absurdly high value (i.e. a negative value), so that we avoid trying to kmalloc
> > > > > upwards of 2G in memdup_user. Your change does that just fine, but its no
> > > > > better or worse than checking for <=0
> > > >
> > > > One can argue that such check against absurdly high values is random
> > > > and not effective, as 2G can be somewhat reasonable on 8GB systems but
> > > > certainly isn't on 512MB ones. On that, kmemdup_user() will also fail
> > > > gracefully as it uses GFP_USER and __GFP_NOWARN.
> > > >
> > > > The original check is more for protecting for sane usage of the
> > > > variable, which is an int, and a negative value is questionable. We
> > > > could cast, yes, but.. was that really the intent of the application?
> > > > Probably not.
> > >
> > > Though that said, I'm okay with the new check here: a quick sanity
> > > check that can avoid expensive calls to kmalloc(), while more refined
> > > check is done later on.
> > >
> > I agree a sanity check makes sense, just to avoid allocating a huge value
> > (even 2G is absurd on many systems), however, I'm not super comfortable with
> > checking for the value being less than 16 (sizeof(sa_family_t)). The zero check
>
> 16 bits you mean then, per
> include/uapi/linux/socket.h
> typedef unsigned short __kernel_sa_family_t;
> include/linux/socket.h
> typedef __kernel_sa_family_t sa_family_t;
>
> > is fairly obvious given the signed nature of the lengh field, this check makes
> > me wonder what exactly we are checking for.
>
> A minimum viable buffer without doing more extensive tests. Beyond
> sa_family, we need to parse sa_family and then that's left for later.
> Perhaps a comment helps, something like
> /* Check if we have at least the family type in there */
> ?
Hm, then this could be
- if (unlikely(addrs_size <= 0))
+ if (unlikely(addrs_size < sizeof(struct sockaddr_in)))
(ipv4)
As it can't be smaller than that, always.
>
> Marcelo
>
> >
> > Neil
> >
> > > >
> > > > >
> > > > > Neil
> > > > >
> > > > > > >
> > > > > > > Neil
> > > > > > >
> > > > > > > > return -EINVAL;
> > > > > > > >
> > > > > > > > kaddrs = memdup_user(addrs, addrs_size);
> > > > > > > > --
> > > > > > > > 2.1.0
> > > > > > > >
> > > > > > > >
> > > > > >
> > >
>
^ permalink raw reply
* INFO: task hung in perf_event_free_task
From: syzbot @ 2019-07-24 19:18 UTC (permalink / raw)
To: acme, alexander.shishkin, ast, bpf, daniel, jolsa, kafai,
linux-kernel, mingo, namhyung, netdev, peterz, songliubraving,
syzkaller-bugs, yhs
Hello,
syzbot found the following crash on:
HEAD commit: c6dd78fc Merge branch 'x86-urgent-for-linus' of git://git...
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10b33b58600000
kernel config: https://syzkaller.appspot.com/x/.config?x=7937b718ddac333b
dashboard link: https://syzkaller.appspot.com/bug?extid=7692cea7450c97fa2a0a
compiler: clang version 9.0.0 (/home/glider/llvm/clang
80fee25776c2fb61e74c1ecb1a523375c2500b69)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=17e888cc600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+7692cea7450c97fa2a0a@syzkaller.appspotmail.com
INFO: task syz-executor.0:9658 blocked for more than 143 seconds.
Not tainted 5.2.0+ #37
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor.0 D25992 9658 7837 0x00004006
Call Trace:
context_switch kernel/sched/core.c:3254 [inline]
__schedule+0x8b7/0xcd0 kernel/sched/core.c:3880
schedule+0x12f/0x1d0 kernel/sched/core.c:3944
perf_event_free_task+0x52a/0x630 kernel/events/core.c:11606
copy_process+0x39bb/0x5a00 kernel/fork.c:2283
_do_fork+0x179/0x630 kernel/fork.c:2369
__do_sys_clone kernel/fork.c:2524 [inline]
__se_sys_clone kernel/fork.c:2505 [inline]
__x64_sys_clone+0x247/0x2b0 kernel/fork.c:2505
do_syscall_64+0xfe/0x140 arch/x86/entry/common.c:296
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x459829
Code: dd fe ff ff cc cc cc cc cc cc cc cc cc cc cc cc cc 64 48 8b 0c 25 f8
ff ff ff 48 3b 61 10 76 68 48 83 ec 28 48 89 6c 24 20 48 <8d> 6c 24 20 48
8b 44 24 30 48 89 04 24 48 8b 4c 24 38 48 89 4c 24
RSP: 002b:00007f2b371d8c78 EFLAGS: 00000246 ORIG_RAX: 0000000000000038
RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 0000000000459829
RDX: 9999999999999999 RSI: 0000000000000000 RDI: 0000002102001ffe
RBP: 000000000075bf20 R08: ffffffffffffffff R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 00007f2b371d96d4
R13: 00000000004bfce6 R14: 00000000004d17f8 R15: 00000000ffffffff
Showing all locks held in the system:
1 lock held by khungtaskd/1056:
#0: 000000004ef21d86 (rcu_read_lock){....}, at: rcu_lock_acquire+0x4/0x30
include/linux/rcupdate.h:207
1 lock held by rsyslogd/7708:
#0: 000000001dbc8cee (&f->f_pos_lock){+.+.}, at: __fdget_pos+0x243/0x2e0
fs/file.c:801
2 locks held by getty/7798:
#0: 00000000ad2eb6b3 (&tty->ldisc_sem){++++}, at:
tty_ldisc_ref_wait+0x25/0x70 drivers/tty/tty_ldisc.c:272
#1: 0000000067bda1b9 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x2ee/0x1c80 drivers/tty/n_tty.c:2156
2 locks held by getty/7799:
#0: 00000000e86f0102 (&tty->ldisc_sem){++++}, at:
tty_ldisc_ref_wait+0x25/0x70 drivers/tty/tty_ldisc.c:272
#1: 00000000f10c3522 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x2ee/0x1c80 drivers/tty/n_tty.c:2156
2 locks held by getty/7800:
#0: 00000000f4a9ed02 (&tty->ldisc_sem){++++}, at:
tty_ldisc_ref_wait+0x25/0x70 drivers/tty/tty_ldisc.c:272
#1: 00000000759669da (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x2ee/0x1c80 drivers/tty/n_tty.c:2156
2 locks held by getty/7801:
#0: 00000000c998e0d2 (&tty->ldisc_sem){++++}, at:
tty_ldisc_ref_wait+0x25/0x70 drivers/tty/tty_ldisc.c:272
#1: 000000007c9ea7de (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x2ee/0x1c80 drivers/tty/n_tty.c:2156
2 locks held by getty/7802:
#0: 00000000398be820 (&tty->ldisc_sem){++++}, at:
tty_ldisc_ref_wait+0x25/0x70 drivers/tty/tty_ldisc.c:272
#1: 00000000deef3632 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x2ee/0x1c80 drivers/tty/n_tty.c:2156
2 locks held by getty/7803:
#0: 00000000fa979d44 (&tty->ldisc_sem){++++}, at:
tty_ldisc_ref_wait+0x25/0x70 drivers/tty/tty_ldisc.c:272
#1: 000000003715a25d (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x2ee/0x1c80 drivers/tty/n_tty.c:2156
2 locks held by getty/7804:
#0: 000000009d01c162 (&tty->ldisc_sem){++++}, at:
tty_ldisc_ref_wait+0x25/0x70 drivers/tty/tty_ldisc.c:272
#1: 0000000010022d29 (&ldata->atomic_read_lock){+.+.}, at:
n_tty_read+0x2ee/0x1c80 drivers/tty/n_tty.c:2156
=============================================
NMI backtrace for cpu 0
CPU: 0 PID: 1056 Comm: khungtaskd Not tainted 5.2.0+ #37
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x1d8/0x2f8 lib/dump_stack.c:113
nmi_cpu_backtrace+0xb0/0x1a0 lib/nmi_backtrace.c:101
nmi_trigger_cpumask_backtrace+0x14c/0x240 lib/nmi_backtrace.c:62
arch_trigger_cpumask_backtrace+0x10/0x20 arch/x86/kernel/apic/hw_nmi.c:38
trigger_all_cpu_backtrace+0x17/0x20 include/linux/nmi.h:146
check_hung_uninterruptible_tasks kernel/hung_task.c:205 [inline]
watchdog+0xbcc/0xbe0 kernel/hung_task.c:289
kthread+0x332/0x350 kernel/kthread.c:255
ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:352
Sending NMI from CPU 0 to CPUs 1:
NMI backtrace for cpu 1 skipped: idling at native_safe_halt+0xe/0x10
arch/x86/include/asm/irqflags.h:60
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* BUG: spinlock recursion in release_sock
From: syzbot @ 2019-07-24 19:18 UTC (permalink / raw)
To: aviadye, borisp, daniel, davejwatson, davem, john.fastabend,
linux-kernel, netdev, syzkaller-bugs
Hello,
syzbot found the following crash on:
HEAD commit: 9e6dfe80 Add linux-next specific files for 20190724
git tree: linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=11c1271fa00000
kernel config: https://syzkaller.appspot.com/x/.config?x=6cbb8fc2cf2842d7
dashboard link: https://syzkaller.appspot.com/bug?extid=e67cf584b5e6b35a8ffa
compiler: gcc (GCC) 9.0.0 20181231 (experimental)
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=13680594600000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=15b34144600000
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+e67cf584b5e6b35a8ffa@syzkaller.appspotmail.com
BUG: spinlock recursion on CPU#0, syz-executor596/9231
lock: 0xffff8880a16c2d08, .magic: dead4ead, .owner:
syz-executor596/9231, .owner_cpu: 0
CPU: 0 PID: 9231 Comm: syz-executor596 Not tainted 5.3.0-rc1-next-20190724
#50
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
Google 01/01/2011
Call Trace:
<IRQ>
__dump_stack lib/dump_stack.c:77 [inline]
dump_stack+0x172/0x1f0 lib/dump_stack.c:113
spin_dump.cold+0x81/0xe6 kernel/locking/spinlock_debug.c:67
spin_bug kernel/locking/spinlock_debug.c:75 [inline]
debug_spin_lock_before kernel/locking/spinlock_debug.c:84 [inline]
do_raw_spin_lock+0x252/0x2e0 kernel/locking/spinlock_debug.c:112
__raw_spin_lock_bh include/linux/spinlock_api_smp.h:136 [inline]
_raw_spin_lock_bh+0x3b/0x50 kernel/locking/spinlock.c:175
spin_lock_bh include/linux/spinlock.h:343 [inline]
release_sock+0x20/0x1c0 net/core/sock.c:2932
wait_on_pending_writer+0x20f/0x420 net/tls/tls_main.c:91
tls_sk_proto_cleanup+0x2c5/0x3e0 net/tls/tls_main.c:295
tls_sk_proto_unhash+0x90/0x3f0 net/tls/tls_main.c:330
tcp_set_state+0x5b9/0x7d0 net/ipv4/tcp.c:2235
tcp_done+0xe2/0x320 net/ipv4/tcp.c:3824
tcp_reset+0x132/0x500 net/ipv4/tcp_input.c:4080
tcp_validate_incoming+0xa2d/0x1660 net/ipv4/tcp_input.c:5440
tcp_rcv_established+0x6b5/0x1e70 net/ipv4/tcp_input.c:5648
tcp_v6_do_rcv+0x41e/0x12c0 net/ipv6/tcp_ipv6.c:1356
tcp_v6_rcv+0x31f1/0x3500 net/ipv6/tcp_ipv6.c:1588
ip6_protocol_deliver_rcu+0x2fe/0x1660 net/ipv6/ip6_input.c:397
ip6_input_finish+0x84/0x170 net/ipv6/ip6_input.c:438
NF_HOOK include/linux/netfilter.h:305 [inline]
NF_HOOK include/linux/netfilter.h:299 [inline]
ip6_input+0xe4/0x3f0 net/ipv6/ip6_input.c:447
dst_input include/net/dst.h:442 [inline]
ip6_rcv_finish+0x1de/0x2f0 net/ipv6/ip6_input.c:76
NF_HOOK include/linux/netfilter.h:305 [inline]
NF_HOOK include/linux/netfilter.h:299 [inline]
ipv6_rcv+0x10e/0x420 net/ipv6/ip6_input.c:272
__netif_receive_skb_one_core+0x113/0x1a0 net/core/dev.c:4999
__netif_receive_skb+0x2c/0x1d0 net/core/dev.c:5113
process_backlog+0x206/0x750 net/core/dev.c:5924
napi_poll net/core/dev.c:6347 [inline]
net_rx_action+0x508/0x10c0 net/core/dev.c:6413
__do_softirq+0x262/0x98c kernel/softirq.c:292
do_softirq_own_stack+0x2a/0x40 arch/x86/entry/entry_64.S:1080
</IRQ>
do_softirq.part.0+0x11a/0x170 kernel/softirq.c:337
do_softirq kernel/softirq.c:329 [inline]
__local_bh_enable_ip+0x211/0x270 kernel/softirq.c:189
local_bh_enable include/linux/bottom_half.h:32 [inline]
inet_csk_listen_stop+0x1e0/0x850 net/ipv4/inet_connection_sock.c:993
tcp_close+0xd5b/0x10e0 net/ipv4/tcp.c:2338
inet_release+0xed/0x200 net/ipv4/af_inet.c:427
inet6_release+0x53/0x80 net/ipv6/af_inet6.c:470
__sock_release+0xce/0x280 net/socket.c:590
sock_close+0x1e/0x30 net/socket.c:1268
__fput+0x2ff/0x890 fs/file_table.c:280
____fput+0x16/0x20 fs/file_table.c:313
task_work_run+0x145/0x1c0 kernel/task_work.c:113
tracehook_notify_resume include/linux/tracehook.h:188 [inline]
exit_to_usermode_loop+0x316/0x380 arch/x86/entry/common.c:163
prepare_exit_to_usermode arch/x86/entry/common.c:194 [inline]
syscall_return_slowpath arch/x86/entry/common.c:274 [inline]
do_syscall_64+0x65f/0x760 arch/x86/entry/common.c:300
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x406581
Code: 75 14 b8 03 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 24 1a 00 00 c3 48
83 ec 08 e8 6a fc ff ff 48 89 04 24 b8 03 00 00 00 0f 05 <48> 8b 3c 24 48
89 c2 e8 b3 fc ff ff 48 89 d0 48 83 c4 08 48 3d 01
RSP: 002b:00007ffd1ccb84a0 EFLAGS: 00000293 ORIG_RAX: 0000000000000003
RAX: 0000000000000000 RBX: 0000000000000005 RCX: 0000000000406581
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000004
RBP: 00000000006dcc20 R08: 0000000000000140 R09: 0000000000000140
R10: 00007ffd1ccb84d0 R11: 0000000000000293 R12: 00007ffd1ccb8500
R13: 00000000006dcc2c R14: 000000000000002d R15: 0000000000000007
---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches
^ permalink raw reply
* [PATCH net-next 0/3] net: ethernet: mediatek: convert to phylink.
From: René van Dorst @ 2019-07-24 19:17 UTC (permalink / raw)
To: netdev
Cc: René van Dorst, Sean Wang, Andrew Lunn, David S . Miller,
Florian Fainelli, Rob Herring, devicetree, Frank Wunderlich,
Russell King, linux-mediatek, linux-mips, John Crispin
These patches converts mediatek driver to phylink api.
SGMII support is only tested with fixed speed of 2.5Gbit on a Bananapi R64.
Frank tested these patches on this Bananapi R64 (mt7622) and
Bananapi R2 (mt7623).
Tested on hardware: mt7621, mt7622 and mt7623.
René van Dorst (3):
net: ethernet: mediatek: Add basic PHYLINK support
net: ethernet: mediatek: Re-add support SGMII
dt-bindings: net: ethernet: Update mt7622 docs and dts to reflect the
new phylink API
.../arm/mediatek/mediatek,sgmiisys.txt | 2 -
.../dts/mediatek/mt7622-bananapi-bpi-r64.dts | 28 +-
arch/arm64/boot/dts/mediatek/mt7622.dtsi | 1 -
drivers/net/ethernet/mediatek/Kconfig | 2 +-
drivers/net/ethernet/mediatek/mtk_eth_path.c | 72 +--
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 486 ++++++++++++------
drivers/net/ethernet/mediatek/mtk_eth_soc.h | 67 ++-
drivers/net/ethernet/mediatek/mtk_sgmii.c | 65 ++-
8 files changed, 436 insertions(+), 287 deletions(-)
To: <netdev@vger.kernel.org>
Cc: Sean Wang <sean.wang@mediatek.com>
Cc: Andrew Lunn <andrew@lunn.ch>
Cc: David S. Miller <davem@davemloft.net>
Cc: Florian Fainelli <f.fainelli@gmail.com>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: Frank Wunderlich <frank-w@public-files.de>
Cc: Russell King <linux@armlinux.org.uk>
Cc: linux-mediatek@lists.infradead.org
Cc: linux-mips@vger.kernel.org
Cc: John Crispin <john@phrozen.org>
--
2.20.1
^ permalink raw reply
* Re: [PATCH bpf-next 0/6] bpf: add BPF_MAP_DUMP command to dump more than one entry per call
From: Song Liu @ 2019-07-24 19:20 UTC (permalink / raw)
To: Brian Vazquez
Cc: Brian Vazquez, Alexei Starovoitov, Daniel Borkmann,
David S . Miller, Stanislav Fomichev, Willem de Bruijn,
Petar Penkov, open list, Networking, bpf
In-Reply-To: <20190724165803.87470-1-brianvv@google.com>
On Wed, Jul 24, 2019 at 10:09 AM Brian Vazquez <brianvv@google.com> wrote:
>
> This introduces a new command to retrieve multiple number of entries
> from a bpf map.
>
> This new command can be executed from the existing BPF syscall as
> follows:
>
> err = bpf(BPF_MAP_DUMP, union bpf_attr *attr, u32 size)
> using attr->dump.map_fd, attr->dump.prev_key, attr->dump.buf,
> attr->dump.buf_len
> returns zero or negative error, and populates buf and buf_len on
> succees
>
> This implementation is wrapping the existing bpf methods:
> map_get_next_key and map_lookup_elem
>
> Note that this implementation can be extended later to do dump and
> delete by extending map_lookup_and_delete_elem (currently it only works
> for bpf queue/stack maps) and either use a new flag in map_dump or a new
> command map_dump_and_delete.
>
> Results show that even with a 1-elem_size buffer, it runs ~40 faster
Why is the new command 40% faster with 1-elem_size buffer?
> than the current implementation, improvements of ~85% are reported when
> the buffer size is increased, although, after the buffer size is around
> 5% of the total number of entries there's no huge difference in
> increasing it.
>
> Tested:
> Tried different size buffers to handle case where the bulk is bigger, or
> the elements to retrieve are less than the existing ones, all runs read
> a map of 100K entries. Below are the results(in ns) from the different
> runs:
>
> buf_len_1: 69038725 entry-by-entry: 112384424 improvement
> 38.569134
> buf_len_2: 40897447 entry-by-entry: 111030546 improvement
> 63.165590
> buf_len_230: 13652714 entry-by-entry: 111694058 improvement
> 87.776687
> buf_len_5000: 13576271 entry-by-entry: 111101169 improvement
> 87.780263
> buf_len_73000: 14694343 entry-by-entry: 111740162 improvement
> 86.849542
> buf_len_100000: 13745969 entry-by-entry: 114151991 improvement
> 87.958187
> buf_len_234567: 14329834 entry-by-entry: 114427589 improvement
> 87.476941
It took me a while to figure out the meaning of 87.476941. It is probably
a good idea to say 87.5% instead.
Thanks,
Song
^ permalink raw reply
* [PATCH net-next 2/3] net: ethernet: mediatek: Re-add support SGMII
From: René van Dorst @ 2019-07-24 19:23 UTC (permalink / raw)
To: netdev
Cc: frank-w, sean.wang, f.fainelli, linux, davem, matthias.bgg,
andrew, vivien.didelot, john, linux-mediatek, linux-mips, robh+dt,
devicetree, René van Dorst
* Re-add SGMII support but now with PHYLINK API support
So the SGMII changes are more clear
* Move SGMII block setup from mtk_gmac_sgmii_path_setup() to
mtk_mac_config()
* Merge mtk_setup_hw_path() into mtk_mac_config()
* Remove mediatek,physpeed property, fixed-link supports now any speed so
speed = <2500>; is now valid with PHYLINK.
* Demagic SGMII register values
* Use phylink state to setup fixed-link mode
Signed-off-by: René van Dorst <opensource@vdorst.com>
Tested-by: Frank Wunderlich <frank-w@public-files.de>
---
drivers/net/ethernet/mediatek/mtk_eth_path.c | 72 +---------
drivers/net/ethernet/mediatek/mtk_eth_soc.c | 130 +++++++++++++++----
drivers/net/ethernet/mediatek/mtk_eth_soc.h | 37 +++++-
drivers/net/ethernet/mediatek/mtk_sgmii.c | 65 ++++++----
4 files changed, 188 insertions(+), 116 deletions(-)
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_path.c b/drivers/net/ethernet/mediatek/mtk_eth_path.c
index 7f05880cf9ef..9a205b9ab1c3 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_path.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_path.c
@@ -239,10 +239,9 @@ static int mtk_eth_mux_setup(struct mtk_eth *eth, int path)
return err;
}
-static int mtk_gmac_sgmii_path_setup(struct mtk_eth *eth, int mac_id)
+int mtk_gmac_sgmii_path_setup(struct mtk_eth *eth, int mac_id)
{
- unsigned int val = 0;
- int sid, err, path;
+ int err, path;
path = (mac_id == 0) ? MTK_ETH_PATH_GMAC1_SGMII :
MTK_ETH_PATH_GMAC2_SGMII;
@@ -252,33 +251,10 @@ static int mtk_gmac_sgmii_path_setup(struct mtk_eth *eth, int mac_id)
if (err)
return err;
- /* The path GMAC to SGMII will be enabled once the SGMIISYS is being
- * setup done.
- */
- regmap_read(eth->ethsys, ETHSYS_SYSCFG0, &val);
-
- regmap_update_bits(eth->ethsys, ETHSYS_SYSCFG0,
- SYSCFG0_SGMII_MASK, ~(u32)SYSCFG0_SGMII_MASK);
-
- /* Decide how GMAC and SGMIISYS be mapped */
- sid = (MTK_HAS_CAPS(eth->soc->caps, MTK_SHARED_SGMII)) ? 0 : mac_id;
-
- /* Setup SGMIISYS with the determined property */
- if (MTK_HAS_FLAGS(eth->sgmii->flags[sid], MTK_SGMII_PHYSPEED_AN))
- err = mtk_sgmii_setup_mode_an(eth->sgmii, sid);
- else
- err = mtk_sgmii_setup_mode_force(eth->sgmii, sid);
-
- if (err)
- return err;
-
- regmap_update_bits(eth->ethsys, ETHSYS_SYSCFG0,
- SYSCFG0_SGMII_MASK, val);
-
return 0;
}
-static int mtk_gmac_gephy_path_setup(struct mtk_eth *eth, int mac_id)
+int mtk_gmac_gephy_path_setup(struct mtk_eth *eth, int mac_id)
{
int err, path = 0;
@@ -296,7 +272,7 @@ static int mtk_gmac_gephy_path_setup(struct mtk_eth *eth, int mac_id)
return 0;
}
-static int mtk_gmac_rgmii_path_setup(struct mtk_eth *eth, int mac_id)
+int mtk_gmac_rgmii_path_setup(struct mtk_eth *eth, int mac_id)
{
int err, path;
@@ -310,43 +286,3 @@ static int mtk_gmac_rgmii_path_setup(struct mtk_eth *eth, int mac_id)
return 0;
}
-
-int mtk_setup_hw_path(struct mtk_eth *eth, int mac_id, int phymode)
-{
- int err;
-
- switch (phymode) {
- case PHY_INTERFACE_MODE_TRGMII:
- case PHY_INTERFACE_MODE_RGMII_TXID:
- case PHY_INTERFACE_MODE_RGMII_RXID:
- case PHY_INTERFACE_MODE_RGMII_ID:
- case PHY_INTERFACE_MODE_RGMII:
- case PHY_INTERFACE_MODE_MII:
- case PHY_INTERFACE_MODE_REVMII:
- case PHY_INTERFACE_MODE_RMII:
- if (MTK_HAS_CAPS(eth->soc->caps, MTK_RGMII)) {
- err = mtk_gmac_rgmii_path_setup(eth, mac_id);
- if (err)
- return err;
- }
- break;
- case PHY_INTERFACE_MODE_SGMII:
- if (MTK_HAS_CAPS(eth->soc->caps, MTK_SGMII)) {
- err = mtk_gmac_sgmii_path_setup(eth, mac_id);
- if (err)
- return err;
- }
- break;
- case PHY_INTERFACE_MODE_GMII:
- if (MTK_HAS_CAPS(eth->soc->caps, MTK_GEPHY)) {
- err = mtk_gmac_gephy_path_setup(eth, mac_id);
- if (err)
- return err;
- }
- break;
- default:
- break;
- }
-
- return 0;
-}
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 853929070cb3..02831166da3c 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -194,7 +194,8 @@ static void mtk_mac_config(struct phylink_config *config, unsigned int mode,
phylink_config);
struct mtk_eth *eth = mac->hw;
- u32 ge_mode = 0, val, mcr_cur, mcr_new;
+ u32 ge_mode = 0, val, mcr_cur, mcr_new, err = -EINVAL;
+ u32 sid;
if (mac->interface != state->interface) {
/* Setup soc pin functions */
@@ -210,24 +211,35 @@ static void mtk_mac_config(struct phylink_config *config, unsigned int mode,
case PHY_INTERFACE_MODE_RGMII_RXID:
case PHY_INTERFACE_MODE_RGMII_ID:
case PHY_INTERFACE_MODE_RGMII:
- break;
case PHY_INTERFACE_MODE_MII:
- ge_mode = 1;
- break;
case PHY_INTERFACE_MODE_REVMII:
- ge_mode = 2;
- break;
case PHY_INTERFACE_MODE_RMII:
- if (mac->id)
- goto err_phy;
- ge_mode = 3;
+ if (MTK_HAS_CAPS(eth->soc->caps, MTK_RGMII)) {
+ err = mtk_gmac_rgmii_path_setup(eth, mac->id);
+ if (err)
+ goto init_err;
+ }
+ break;
+ case PHY_INTERFACE_MODE_SGMII:
+ if (MTK_HAS_CAPS(eth->soc->caps, MTK_SGMII)) {
+ err = mtk_gmac_sgmii_path_setup(eth, mac->id);
+ if (err)
+ goto init_err;
+ }
+ break;
+ case PHY_INTERFACE_MODE_GMII:
+ if (MTK_HAS_CAPS(eth->soc->caps, MTK_GEPHY)) {
+ err = mtk_gmac_gephy_path_setup(eth, mac->id);
+ if (err)
+ goto init_err;
+ }
break;
default:
goto err_phy;
}
/* Setup clock for 1st gmac */
- if (!mac->id &&
+ if (!mac->id && state->interface != PHY_INTERFACE_MODE_SGMII &&
MTK_HAS_CAPS(mac->hw->soc->caps, MTK_GMAC1_TRGMII)) {
if (MTK_HAS_CAPS(mac->hw->soc->caps,
MTK_TRGMII_MT7621_CLK)) {
@@ -242,6 +254,22 @@ static void mtk_mac_config(struct phylink_config *config, unsigned int mode,
}
}
+ switch (state->interface) {
+ case PHY_INTERFACE_MODE_MII:
+ ge_mode = 1;
+ break;
+ case PHY_INTERFACE_MODE_REVMII:
+ ge_mode = 2;
+ break;
+ case PHY_INTERFACE_MODE_RMII:
+ if (mac->id)
+ goto err_phy;
+ ge_mode = 3;
+ break;
+ default:
+ break;
+ }
+
/* put the gmac into the right mode */
regmap_read(eth->ethsys, ETHSYS_SYSCFG0, &val);
val &= ~SYSCFG0_GE_MODE(SYSCFG0_GE_MASK, mac->id);
@@ -251,7 +279,38 @@ static void mtk_mac_config(struct phylink_config *config, unsigned int mode,
mac->interface = state->interface;
}
- /* Setup gmac */
+ /* SGMII */
+ if (state->interface == PHY_INTERFACE_MODE_SGMII) {
+ /* The path GMAC to SGMII will be enabled once the SGMIISYS is
+ * being setup done.
+ */
+ regmap_read(eth->ethsys, ETHSYS_SYSCFG0, &val);
+
+ regmap_update_bits(eth->ethsys, ETHSYS_SYSCFG0,
+ SYSCFG0_SGMII_MASK,
+ ~(u32)SYSCFG0_SGMII_MASK);
+
+ /* Decide how GMAC and SGMIISYS be mapped */
+ sid = (MTK_HAS_CAPS(eth->soc->caps, MTK_SHARED_SGMII)) ?
+ 0 : mac->id;
+
+ /* Setup SGMIISYS with the determined property */
+ if (phylink_autoneg_inband(mode))
+ err = mtk_sgmii_setup_mode_an(eth->sgmii, sid);
+ else
+ err = mtk_sgmii_setup_mode_force(eth->sgmii, sid,
+ state);
+ if (err)
+ goto init_err;
+
+ regmap_update_bits(eth->ethsys, ETHSYS_SYSCFG0,
+ SYSCFG0_SGMII_MASK, val);
+ } else if (phylink_autoneg_inband(mode)) {
+ dev_err(eth->dev, "In-band mode not supported in non SGMII mode!\n");
+ return;
+ }
+
+ /* Setup GMAC */
mcr_cur = mtk_r32(mac->hw, MTK_MAC_MCR(mac->id));
mcr_new = mcr_cur;
mcr_new &= ~(MAC_MCR_SPEED_100 | MAC_MCR_SPEED_1000 |
@@ -261,6 +320,7 @@ static void mtk_mac_config(struct phylink_config *config, unsigned int mode,
MAC_MCR_BACKOFF_EN | MAC_MCR_BACKPR_EN | MAC_MCR_FORCE_LINK;
switch (state->speed) {
+ case SPEED_2500:
case SPEED_1000:
mcr_new |= MAC_MCR_SPEED_1000;
break;
@@ -285,6 +345,11 @@ static void mtk_mac_config(struct phylink_config *config, unsigned int mode,
err_phy:
dev_err(eth->dev, "%s: GMAC%d mode %s not supported!\n", __func__,
mac->id, phy_modes(state->interface));
+ return;
+
+init_err:
+ dev_err(eth->dev, "%s: GMAC%d mode %s err: %d!\n", __func__,
+ mac->id, phy_modes(state->interface), err);
}
static int mtk_mac_link_state(struct phylink_config *config,
@@ -325,7 +390,10 @@ static int mtk_mac_link_state(struct phylink_config *config,
static void mtk_mac_an_restart(struct phylink_config *config)
{
- /* Do nothing */
+ struct mtk_mac *mac = container_of(config, struct mtk_mac,
+ phylink_config);
+
+ mtk_sgmii_restart_an(mac->hw, mac->id);
}
static void mtk_mac_link_down(struct phylink_config *config, unsigned int mode,
@@ -362,7 +430,10 @@ static void mtk_validate(struct phylink_config *config,
state->interface != PHY_INTERFACE_MODE_MII &&
!(!mac->id && state->interface == PHY_INTERFACE_MODE_TRGMII &&
MTK_HAS_CAPS(mac->hw->soc->caps, MTK_TRGMII)) &&
- !phy_interface_mode_is_rgmii(state->interface)) {
+ !phy_interface_mode_is_rgmii(state->interface) &&
+ !(MTK_HAS_CAPS(mac->hw->soc->caps, MTK_SGMII) &&
+ (state->interface == PHY_INTERFACE_MODE_SGMII ||
+ phy_interface_mode_is_8023z(state->interface)))) {
linkmode_zero(supported);
return;
}
@@ -370,17 +441,27 @@ static void mtk_validate(struct phylink_config *config,
phylink_set_port_modes(mask);
phylink_set(mask, Autoneg);
- if (state->interface == PHY_INTERFACE_MODE_TRGMII) {
- phylink_set(mask, 1000baseT_Full);
+ if (MTK_HAS_CAPS(mac->hw->soc->caps, MTK_SGMII)) {
+ if (state->interface != PHY_INTERFACE_MODE_2500BASEX) {
+ phylink_set(mask, 1000baseT_Full);
+ phylink_set(mask, 1000baseX_Full);
+ } else {
+ phylink_set(mask, 2500baseT_Full);
+ phylink_set(mask, 2500baseX_Full);
+ }
} else {
- phylink_set(mask, 10baseT_Half);
- phylink_set(mask, 10baseT_Full);
- phylink_set(mask, 100baseT_Half);
- phylink_set(mask, 100baseT_Full);
-
- if (state->interface != PHY_INTERFACE_MODE_MII) {
- phylink_set(mask, 1000baseT_Half);
+ if (state->interface == PHY_INTERFACE_MODE_TRGMII) {
phylink_set(mask, 1000baseT_Full);
+ } else {
+ phylink_set(mask, 10baseT_Half);
+ phylink_set(mask, 10baseT_Full);
+ phylink_set(mask, 100baseT_Half);
+ phylink_set(mask, 100baseT_Full);
+
+ if (state->interface != PHY_INTERFACE_MODE_MII) {
+ phylink_set(mask, 1000baseT_Half);
+ phylink_set(mask, 1000baseT_Full);
+ }
}
}
@@ -389,6 +470,11 @@ static void mtk_validate(struct phylink_config *config,
linkmode_and(supported, supported, mask);
linkmode_and(state->advertising, state->advertising, mask);
+
+ /* We can only operate at 2500BaseX or 1000BaseX. If requested
+ * to advertise both, only report advertising at 2500BaseX.
+ */
+ phylink_helper_basex_speed(state);
}
static const struct phylink_mac_ops mtk_phylink_ops = {
diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.h b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
index 3bfcba9ffb58..c25d611f38c6 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.h
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.h
@@ -401,14 +401,38 @@
/* Register to auto-negotiation restart */
#define SGMSYS_PCS_CONTROL_1 0x0
#define SGMII_AN_RESTART BIT(9)
+#define SGMII_ISOLATE BIT(10)
+#define SGMII_AN_ENABLE BIT(12)
+#define SGMII_LINK_STATYS BIT(18)
+#define SGMII_AN_ABILITY BIT(19)
+#define SGMII_AN_COMPLETE BIT(21)
+#define SGMII_PCS_FAULT BIT(23)
+#define SGMII_AN_EXPANSION_CLR BIT(30)
/* Register to programmable link timer, the unit in 2 * 8ns */
#define SGMSYS_PCS_LINK_TIMER 0x18
#define SGMII_LINK_TIMER_DEFAULT (0x186a0 & GENMASK(19, 0))
/* Register to control remote fault */
-#define SGMSYS_SGMII_MODE 0x20
-#define SGMII_REMOTE_FAULT_DIS BIT(8)
+#define SGMSYS_SGMII_MODE 0x20
+#define SGMII_IF_MODE_BIT0 BIT(0)
+#define SGMII_SPEED_DUPLEX_AN BIT(1)
+#define SGMII_SPEED_10 0x0
+#define SGMII_SPEED_100 BIT(2)
+#define SGMII_SPEED_1000 BIT(3)
+#define SGMII_DUPLEX_FULL BIT(4)
+#define SGMII_IF_MODE_BIT5 BIT(5)
+#define SGMII_REMOTE_FAULT_DIS BIT(8)
+#define SGMII_CODE_SYNC_SET_VAL BIT(9)
+#define SGMII_CODE_SYNC_SET_EN BIT(10)
+#define SGMII_SEND_AN_ERROR_EN BIT(11)
+#define SGMII_IF_MODE_MASK GENMASK(5, 1)
+
+/* Register to set SGMII speed, ANA RG_ Control Signals III*/
+#define SGMSYS_ANA_RG_CS3 0x2028
+#define RG_PHY_SPEED_MASK (BIT(2) | BIT(3))
+#define RG_PHY_SPEED_1_25G 0x0
+#define RG_PHY_SPEED_3_125G BIT(2)
/* Register to power up QPHY */
#define SGMSYS_QPHY_PWR_STATE_CTRL 0xe8
@@ -853,7 +877,12 @@ u32 mtk_r32(struct mtk_eth *eth, unsigned reg);
int mtk_sgmii_init(struct mtk_sgmii *ss, struct device_node *np,
u32 ana_rgc3);
int mtk_sgmii_setup_mode_an(struct mtk_sgmii *ss, int id);
-int mtk_sgmii_setup_mode_force(struct mtk_sgmii *ss, int id);
-int mtk_setup_hw_path(struct mtk_eth *eth, int mac_id, int phymode);
+int mtk_sgmii_setup_mode_force(struct mtk_sgmii *ss, int id,
+ const struct phylink_link_state *state);
+void mtk_sgmii_restart_an(struct mtk_eth *eth, int mac_id);
+
+int mtk_gmac_sgmii_path_setup(struct mtk_eth *eth, int mac_id);
+int mtk_gmac_gephy_path_setup(struct mtk_eth *eth, int mac_id);
+int mtk_gmac_rgmii_path_setup(struct mtk_eth *eth, int mac_id);
#endif /* MTK_ETH_H */
diff --git a/drivers/net/ethernet/mediatek/mtk_sgmii.c b/drivers/net/ethernet/mediatek/mtk_sgmii.c
index ff509d42d818..3032c54403d2 100644
--- a/drivers/net/ethernet/mediatek/mtk_sgmii.c
+++ b/drivers/net/ethernet/mediatek/mtk_sgmii.c
@@ -16,8 +16,7 @@
int mtk_sgmii_init(struct mtk_sgmii *ss, struct device_node *r, u32 ana_rgc3)
{
struct device_node *np;
- const char *str;
- int i, err;
+ int i;
ss->ana_rgc3 = ana_rgc3;
@@ -29,19 +28,6 @@ int mtk_sgmii_init(struct mtk_sgmii *ss, struct device_node *r, u32 ana_rgc3)
ss->regmap[i] = syscon_node_to_regmap(np);
if (IS_ERR(ss->regmap[i]))
return PTR_ERR(ss->regmap[i]);
-
- err = of_property_read_string(np, "mediatek,physpeed", &str);
- if (err)
- return err;
-
- if (!strcmp(str, "2500"))
- ss->flags[i] |= MTK_SGMII_PHYSPEED_2500;
- else if (!strcmp(str, "1000"))
- ss->flags[i] |= MTK_SGMII_PHYSPEED_1000;
- else if (!strcmp(str, "auto"))
- ss->flags[i] |= MTK_SGMII_PHYSPEED_AN;
- else
- return -EINVAL;
}
return 0;
@@ -73,27 +59,45 @@ int mtk_sgmii_setup_mode_an(struct mtk_sgmii *ss, int id)
return 0;
}
-int mtk_sgmii_setup_mode_force(struct mtk_sgmii *ss, int id)
+int mtk_sgmii_setup_mode_force(struct mtk_sgmii *ss, int id,
+ const struct phylink_link_state *state)
{
unsigned int val;
- int mode;
if (!ss->regmap[id])
return -EINVAL;
regmap_read(ss->regmap[id], ss->ana_rgc3, &val);
- val &= ~GENMASK(3, 2);
- mode = ss->flags[id] & MTK_SGMII_PHYSPEED_MASK;
- val |= (mode == MTK_SGMII_PHYSPEED_1000) ? 0 : BIT(2);
+ val &= ~RG_PHY_SPEED_MASK;
+ if (state->speed == SPEED_2500)
+ val |= RG_PHY_SPEED_3_125G;
regmap_write(ss->regmap[id], ss->ana_rgc3, val);
/* Disable SGMII AN */
regmap_read(ss->regmap[id], SGMSYS_PCS_CONTROL_1, &val);
- val &= ~BIT(12);
+ val &= ~SGMII_AN_ENABLE;
regmap_write(ss->regmap[id], SGMSYS_PCS_CONTROL_1, val);
/* SGMII force mode setting */
- val = 0x31120019;
+ regmap_read(ss->regmap[id], SGMSYS_SGMII_MODE, &val);
+ val &= ~SGMII_IF_MODE_MASK;
+
+ switch (state->speed) {
+ case SPEED_10:
+ val |= SGMII_SPEED_10;
+ break;
+ case SPEED_100:
+ val |= SGMII_SPEED_100;
+ break;
+ case SPEED_2500:
+ case SPEED_1000:
+ val |= SGMII_SPEED_1000;
+ break;
+ };
+
+ if (state->duplex == DUPLEX_FULL)
+ val |= SGMII_DUPLEX_FULL;
+
regmap_write(ss->regmap[id], SGMSYS_SGMII_MODE, val);
/* Release PHYA power down state */
@@ -103,3 +107,20 @@ int mtk_sgmii_setup_mode_force(struct mtk_sgmii *ss, int id)
return 0;
}
+
+void mtk_sgmii_restart_an(struct mtk_eth *eth, int mac_id)
+{
+ struct mtk_sgmii *ss = eth->sgmii;
+ unsigned int val, sid;
+
+ /* Decide how GMAC and SGMIISYS be mapped */
+ sid = (MTK_HAS_CAPS(eth->soc->caps, MTK_SHARED_SGMII)) ?
+ 0 : mac_id;
+
+ if (!ss->regmap[sid])
+ return;
+
+ regmap_read(ss->regmap[sid], SGMSYS_PCS_CONTROL_1, &val);
+ val |= SGMII_AN_RESTART;
+ regmap_write(ss->regmap[sid], SGMSYS_PCS_CONTROL_1, val);
+}
--
2.20.1
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox