* Re: pull-request: wireless-drivers 2018-11-20
From: David Miller @ 2018-11-21 23:51 UTC (permalink / raw)
To: kvalo; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <87k1l7bwps.fsf@kamboji.qca.qualcomm.com>
From: Kalle Valo <kvalo@codeaurora.org>
Date: Tue, 20 Nov 2018 17:22:07 +0200
> here's a pull request to net tree for 4.20, more info below. Please let
> me know if there are any problems.
Pulled, thank you.
^ permalink raw reply
* [PATCH v3 5/5] Bluetooth: btusb: Use the hw_reset method to allow resetting the BT chip
From: Rajat Jain @ 2018-11-21 23:50 UTC (permalink / raw)
To: Marcel Holtmann, Johan Hedberg, Greg Kroah-Hartman,
David S. Miller, Dmitry Torokhov, Rajat Jain, Alex Hung,
linux-bluetooth, linux-kernel, linux-usb, netdev
Cc: rajatxjain, dtor, raghuram.hegde, chethan.tumkur.narayan,
sukumar.ghorai
In-Reply-To: <20181121235020.29461-1-rajatja@google.com>
If the platform provides it, use the reset gpio to reset the BT
chip (requested by the HCI core if needed). This has been found helpful
on some of Intel bluetooth controllers where the firmware gets stuck and
the only way out is a hard reset pin provided by the platform.
Signed-off-by: Rajat Jain <rajatja@google.com>
---
v3: Better error handling for gpiod_get_optional()
v2: Handle the EPROBE_DEFER case.
drivers/bluetooth/btusb.c | 40 +++++++++++++++++++++++++++++++++++++++
1 file changed, 40 insertions(+)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index e8e148480c91..e7631f770fae 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -29,6 +29,7 @@
#include <linux/of_device.h>
#include <linux/of_irq.h>
#include <linux/suspend.h>
+#include <linux/gpio/consumer.h>
#include <asm/unaligned.h>
#include <net/bluetooth/bluetooth.h>
@@ -475,6 +476,8 @@ struct btusb_data {
struct usb_endpoint_descriptor *diag_tx_ep;
struct usb_endpoint_descriptor *diag_rx_ep;
+ struct gpio_desc *reset_gpio;
+
__u8 cmdreq_type;
__u8 cmdreq;
@@ -490,6 +493,26 @@ struct btusb_data {
int oob_wake_irq; /* irq for out-of-band wake-on-bt */
};
+
+static void btusb_hw_reset(struct hci_dev *hdev)
+{
+ struct btusb_data *data = hci_get_drvdata(hdev);
+ struct gpio_desc *reset_gpio = data->reset_gpio;
+
+ /*
+ * Toggle the hard reset line if the platform provides one. The reset
+ * is going to yank the device off the USB and then replug. So doing
+ * once is enough. The cleanup is handled correctly on the way out
+ * (standard USB disconnect), and the new device is detected cleanly
+ * and bound to the driver again like it should be.
+ */
+ bt_dev_dbg(hdev, "%s: Initiating HW reset via gpio", __func__);
+ clear_bit(HCI_QUIRK_HW_RESET_ON_TIMEOUT, &hdev->quirks);
+ gpiod_set_value(reset_gpio, 1);
+ mdelay(100);
+ gpiod_set_value(reset_gpio, 0);
+}
+
static inline void btusb_free_frags(struct btusb_data *data)
{
unsigned long flags;
@@ -2917,6 +2940,7 @@ static int btusb_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
struct usb_endpoint_descriptor *ep_desc;
+ struct gpio_desc *reset_gpio;
struct btusb_data *data;
struct hci_dev *hdev;
unsigned ifnum_base;
@@ -3030,6 +3054,16 @@ static int btusb_probe(struct usb_interface *intf,
SET_HCIDEV_DEV(hdev, &intf->dev);
+ reset_gpio = gpiod_get_optional(&data->udev->dev, "reset",
+ GPIOD_OUT_LOW);
+ if (IS_ERR(reset_gpio)) {
+ err = PTR_ERR(reset_gpio);
+ goto out_free_dev;
+ } else if (reset_gpio) {
+ data->reset_gpio = reset_gpio;
+ hdev->hw_reset = btusb_hw_reset;
+ }
+
hdev->open = btusb_open;
hdev->close = btusb_close;
hdev->flush = btusb_flush;
@@ -3085,6 +3119,7 @@ static int btusb_probe(struct usb_interface *intf,
set_bit(HCI_QUIRK_STRICT_DUPLICATE_FILTER, &hdev->quirks);
set_bit(HCI_QUIRK_SIMULTANEOUS_DISCOVERY, &hdev->quirks);
set_bit(HCI_QUIRK_NON_PERSISTENT_DIAG, &hdev->quirks);
+ set_bit(HCI_QUIRK_HW_RESET_ON_TIMEOUT, &hdev->quirks);
if (id->driver_info & BTUSB_INTEL) {
hdev->setup = btusb_setup_intel;
@@ -3225,6 +3260,8 @@ static int btusb_probe(struct usb_interface *intf,
return 0;
out_free_dev:
+ if (data->reset_gpio)
+ gpiod_put(data->reset_gpio);
hci_free_dev(hdev);
return err;
}
@@ -3268,6 +3305,9 @@ static void btusb_disconnect(struct usb_interface *intf)
if (data->oob_wake_irq)
device_init_wakeup(&data->udev->dev, false);
+ if (data->reset_gpio)
+ gpiod_put(data->reset_gpio);
+
hci_free_dev(hdev);
}
--
2.19.1.1215.g8438c0b245-goog
^ permalink raw reply related
* [PATCH v3 4/5] Bluetooth: btusb: Collect the common Intel assignments together
From: Rajat Jain @ 2018-11-21 23:50 UTC (permalink / raw)
To: Marcel Holtmann, Johan Hedberg, Greg Kroah-Hartman,
David S. Miller, Dmitry Torokhov, Rajat Jain, Alex Hung,
linux-bluetooth, linux-kernel, linux-usb, netdev
Cc: rajatxjain, dtor, raghuram.hegde, chethan.tumkur.narayan,
sukumar.ghorai
In-Reply-To: <20181121235020.29461-1-rajatja@google.com>
The BTUSB_INTEL and BTUSB_INTEL_NEW have common functions & quirks are
assigned to hdev structure. Lets collect them together instead of
repeating them in different code branches.
Signed-off-by: Rajat Jain <rajatja@google.com>
---
v3: same as v1
v2: same as v1
drivers/bluetooth/btusb.c | 27 ++++++++++++---------------
1 file changed, 12 insertions(+), 15 deletions(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 7439a7eb50ac..e8e148480c91 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -3077,28 +3077,25 @@ static int btusb_probe(struct usb_interface *intf,
data->diag = usb_ifnum_to_if(data->udev, ifnum_base + 2);
}
#endif
+ if (id->driver_info & BTUSB_INTEL ||
+ id->driver_info & BTUSB_INTEL_NEW) {
- if (id->driver_info & BTUSB_INTEL) {
hdev->manufacturer = 2;
- hdev->setup = btusb_setup_intel;
- hdev->shutdown = btusb_shutdown_intel;
- hdev->set_diag = btintel_set_diag_mfg;
hdev->set_bdaddr = btintel_set_bdaddr;
set_bit(HCI_QUIRK_STRICT_DUPLICATE_FILTER, &hdev->quirks);
set_bit(HCI_QUIRK_SIMULTANEOUS_DISCOVERY, &hdev->quirks);
set_bit(HCI_QUIRK_NON_PERSISTENT_DIAG, &hdev->quirks);
- }
- if (id->driver_info & BTUSB_INTEL_NEW) {
- hdev->manufacturer = 2;
- hdev->send = btusb_send_frame_intel;
- hdev->setup = btusb_setup_intel_new;
- hdev->hw_error = btintel_hw_error;
- hdev->set_diag = btintel_set_diag;
- hdev->set_bdaddr = btintel_set_bdaddr;
- set_bit(HCI_QUIRK_STRICT_DUPLICATE_FILTER, &hdev->quirks);
- set_bit(HCI_QUIRK_SIMULTANEOUS_DISCOVERY, &hdev->quirks);
- set_bit(HCI_QUIRK_NON_PERSISTENT_DIAG, &hdev->quirks);
+ if (id->driver_info & BTUSB_INTEL) {
+ hdev->setup = btusb_setup_intel;
+ hdev->shutdown = btusb_shutdown_intel;
+ hdev->set_diag = btintel_set_diag_mfg;
+ } else {
+ hdev->send = btusb_send_frame_intel;
+ hdev->setup = btusb_setup_intel_new;
+ hdev->hw_error = btintel_hw_error;
+ hdev->set_diag = btintel_set_diag;
+ }
}
if (id->driver_info & BTUSB_MARVELL)
--
2.19.1.1215.g8438c0b245-goog
^ permalink raw reply related
* [PATCH v3 3/5] Bluetooth: Reset Bluetooth chip after multiple command timeouts
From: Rajat Jain @ 2018-11-21 23:50 UTC (permalink / raw)
To: Marcel Holtmann, Johan Hedberg, Greg Kroah-Hartman,
David S. Miller, Dmitry Torokhov, Rajat Jain, Alex Hung,
linux-bluetooth, linux-kernel, linux-usb, netdev
Cc: rajatxjain, dtor, raghuram.hegde, chethan.tumkur.narayan,
sukumar.ghorai
In-Reply-To: <20181121235020.29461-1-rajatja@google.com>
Add a quirk and a hook to allow the HCI core to reset the BT chip
if needed (after a number of timed out commands). Use that new hook to
initiate BT chip reset if the controller fails to respond to certain
number of commands (currently 5) including the HCI reset commands.
This is done based on a newly introduced quirk. This is done based
on some initial work by Intel.
Signed-off-by: Rajat Jain <rajatja@google.com>
---
v3: same as v1
v2: same as v1
include/net/bluetooth/hci.h | 8 ++++++++
include/net/bluetooth/hci_core.h | 2 ++
net/bluetooth/hci_core.c | 15 +++++++++++++--
3 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/include/net/bluetooth/hci.h b/include/net/bluetooth/hci.h
index c36dc1e20556..af02fa5ffe54 100644
--- a/include/net/bluetooth/hci.h
+++ b/include/net/bluetooth/hci.h
@@ -192,6 +192,14 @@ enum {
*
*/
HCI_QUIRK_NON_PERSISTENT_SETUP,
+
+ /* When this quirk is set, hw_reset() would be run to reset the
+ * hardware, after a certain number of commands (currently 5)
+ * time out because the device fails to respond.
+ *
+ * This quirk should be set before hci_register_dev is called.
+ */
+ HCI_QUIRK_HW_RESET_ON_TIMEOUT,
};
/* HCI device flags */
diff --git a/include/net/bluetooth/hci_core.h b/include/net/bluetooth/hci_core.h
index e5ea633ea368..b86218304b80 100644
--- a/include/net/bluetooth/hci_core.h
+++ b/include/net/bluetooth/hci_core.h
@@ -313,6 +313,7 @@ struct hci_dev {
unsigned int acl_cnt;
unsigned int sco_cnt;
unsigned int le_cnt;
+ unsigned int timeout_cnt;
unsigned int acl_mtu;
unsigned int sco_mtu;
@@ -437,6 +438,7 @@ struct hci_dev {
int (*post_init)(struct hci_dev *hdev);
int (*set_diag)(struct hci_dev *hdev, bool enable);
int (*set_bdaddr)(struct hci_dev *hdev, const bdaddr_t *bdaddr);
+ void (*hw_reset)(struct hci_dev *hdev);
};
#define HCI_PHY_HANDLE(handle) (handle & 0xff)
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 7352fe85674b..ab3a6a8b7ba6 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -2569,13 +2569,24 @@ static void hci_cmd_timeout(struct work_struct *work)
struct hci_dev *hdev = container_of(work, struct hci_dev,
cmd_timer.work);
+ hdev->timeout_cnt++;
if (hdev->sent_cmd) {
struct hci_command_hdr *sent = (void *) hdev->sent_cmd->data;
u16 opcode = __le16_to_cpu(sent->opcode);
- bt_dev_err(hdev, "command 0x%4.4x tx timeout", opcode);
+ bt_dev_err(hdev, "command 0x%4.4x tx timeout (cnt = %u)",
+ opcode, hdev->timeout_cnt);
} else {
- bt_dev_err(hdev, "command tx timeout");
+ bt_dev_err(hdev, "command tx timeout (cnt = %u)",
+ hdev->timeout_cnt);
+ }
+
+ if (test_bit(HCI_QUIRK_HW_RESET_ON_TIMEOUT, &hdev->quirks) &&
+ hdev->timeout_cnt >= 5) {
+ hdev->timeout_cnt = 0;
+ if (hdev->hw_reset)
+ hdev->hw_reset(hdev);
+ return;
}
atomic_set(&hdev->cmd_cnt, 1);
--
2.19.1.1215.g8438c0b245-goog
^ permalink raw reply related
* [PATCH v3 2/5] usb: assign ACPI companions for embedded USB devices
From: Rajat Jain @ 2018-11-21 23:50 UTC (permalink / raw)
To: Marcel Holtmann, Johan Hedberg, Greg Kroah-Hartman,
David S. Miller, Dmitry Torokhov, Rajat Jain, Alex Hung,
linux-bluetooth, linux-kernel, linux-usb, netdev
Cc: rajatxjain, dtor, raghuram.hegde, chethan.tumkur.narayan,
sukumar.ghorai
In-Reply-To: <20181121235020.29461-1-rajatja@google.com>
From: Dmitry Torokhov <dtor@chromium.org>
USB devices permanently connected to USB ports may be described in ACPI
tables and share ACPI devices with ports they are connected to. See [1]
for details.
This will allow us to describe sideband resources for devices, such as,
for example, hard reset line for BT USB controllers.
[1] https://docs.microsoft.com/en-us/windows-hardware/drivers/bringup/other-acpi-namespace-objects#acpi-namespace-hierarchy-and-adr-for-embedded-usb-devices
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Signed-off-by: Rajat Jain <rajatja@google.com> (changed how we get the usb_port)
---
v3: same as v1
v2: same as v1
drivers/usb/core/usb-acpi.c | 44 +++++++++++++++++++++++++++++--------
1 file changed, 35 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/core/usb-acpi.c b/drivers/usb/core/usb-acpi.c
index 8ff73c83e8e8..9043d7242d67 100644
--- a/drivers/usb/core/usb-acpi.c
+++ b/drivers/usb/core/usb-acpi.c
@@ -200,30 +200,56 @@ static struct acpi_device *
usb_acpi_find_companion_for_device(struct usb_device *udev)
{
struct acpi_device *adev;
+ struct usb_port *port_dev;
+ struct usb_hub *hub;
+
+ if (!udev->parent) {
+ /* root hub is only child (_ADR=0) under its parent, the HC */
+ adev = ACPI_COMPANION(udev->dev.parent);
+ return acpi_find_child_device(adev, 0, false);
+ }
- if (!udev->parent)
+ hub = usb_hub_to_struct_hub(udev->parent);
+ if (!hub)
return NULL;
- /* root hub is only child (_ADR=0) under its parent, the HC */
- adev = ACPI_COMPANION(udev->dev.parent);
- return acpi_find_child_device(adev, 0, false);
+ /*
+ * This is an embedded USB device connected to a port and such
+ * devices share port's ACPI companion.
+ */
+ port_dev = hub->ports[udev->portnum - 1];
+ return usb_acpi_get_companion_for_port(port_dev);
}
-
static struct acpi_device *usb_acpi_find_companion(struct device *dev)
{
/*
- * In the ACPI DSDT table, only usb root hub and usb ports are
- * acpi device nodes. The hierarchy like following.
+ * The USB hierarchy like following:
+ *
* Device (EHC1)
* Device (HUBN)
* Device (PR01)
* Device (PR11)
* Device (PR12)
+ * Device (FN12)
+ * Device (FN13)
* Device (PR13)
* ...
- * So all binding process is divided into two parts. binding
- * root hub and usb ports.
+ * where HUBN is root hub, and PRNN are USB ports and devices
+ * connected to them, and FNNN are individualk functions for
+ * connected composite USB devices. PRNN and FNNN may contain
+ * _CRS and other methods describing sideband resources for
+ * the connected device.
+ *
+ * On the kernel side both root hub and embedded USB devices are
+ * represented as instances of usb_device structure, and ports
+ * are represented as usb_port structures, so the whole process
+ * is split into 2 parts: finding companions for devices and
+ * finding companions for ports.
+ *
+ * Note that we do not handle individual functions of composite
+ * devices yet, for that we would need to assign companions to
+ * devices corresponding to USB interfaces.
*/
if (is_usb_device(dev))
return usb_acpi_find_companion_for_device(to_usb_device(dev));
--
2.19.1.1215.g8438c0b245-goog
^ permalink raw reply related
* [PATCH v3 1/5] usb: split code locating ACPI companion into port and device
From: Rajat Jain @ 2018-11-21 23:50 UTC (permalink / raw)
To: Marcel Holtmann, Johan Hedberg, Greg Kroah-Hartman,
David S. Miller, Dmitry Torokhov, Rajat Jain, Alex Hung,
linux-bluetooth, linux-kernel, linux-usb, netdev
Cc: rajatxjain, dtor, raghuram.hegde, chethan.tumkur.narayan,
sukumar.ghorai
In-Reply-To: <20181117010748.24347-1-rajatja@google.com>
From: Dmitry Torokhov <dtor@chromium.org>
In preparation for handling embedded USB devices let's split
usb_acpi_find_companion() into usb_acpi_find_companion_for_device() and
usb_acpi_find_companion_for_port().
Signed-off-by: Dmitry Torokhov <dtor@chromium.org>
Signed-off-by: Rajat Jain <rajatja@google.com>
---
v3: same as v1
v2: same as v1
drivers/usb/core/usb-acpi.c | 133 +++++++++++++++++++-----------------
1 file changed, 72 insertions(+), 61 deletions(-)
diff --git a/drivers/usb/core/usb-acpi.c b/drivers/usb/core/usb-acpi.c
index e221861b3187..8ff73c83e8e8 100644
--- a/drivers/usb/core/usb-acpi.c
+++ b/drivers/usb/core/usb-acpi.c
@@ -139,12 +139,79 @@ static struct acpi_device *usb_acpi_find_port(struct acpi_device *parent,
return acpi_find_child_device(parent, raw, false);
}
-static struct acpi_device *usb_acpi_find_companion(struct device *dev)
+static struct acpi_device *
+usb_acpi_get_companion_for_port(struct usb_port *port_dev)
{
struct usb_device *udev;
struct acpi_device *adev;
acpi_handle *parent_handle;
+ int port1;
+
+ /* Get the struct usb_device point of port's hub */
+ udev = to_usb_device(port_dev->dev.parent->parent);
+
+ /*
+ * The root hub ports' parent is the root hub. The non-root-hub
+ * ports' parent is the parent hub port which the hub is
+ * connected to.
+ */
+ if (!udev->parent) {
+ adev = ACPI_COMPANION(&udev->dev);
+ port1 = usb_hcd_find_raw_port_number(bus_to_hcd(udev->bus),
+ port_dev->portnum);
+ } else {
+ parent_handle = usb_get_hub_port_acpi_handle(udev->parent,
+ udev->portnum);
+ if (!parent_handle)
+ return NULL;
+
+ acpi_bus_get_device(parent_handle, &adev);
+ port1 = port_dev->portnum;
+ }
+
+ return usb_acpi_find_port(adev, port1);
+}
+
+static struct acpi_device *
+usb_acpi_find_companion_for_port(struct usb_port *port_dev)
+{
+ struct acpi_device *adev;
+ struct acpi_pld_info *pld;
+ acpi_handle *handle;
+ acpi_status status;
+
+ adev = usb_acpi_get_companion_for_port(port_dev);
+ if (!adev)
+ return NULL;
+
+ handle = adev->handle;
+ status = acpi_get_physical_device_location(handle, &pld);
+ if (!ACPI_FAILURE(status) && pld) {
+ port_dev->location = USB_ACPI_LOCATION_VALID
+ | pld->group_token << 8 | pld->group_position;
+ port_dev->connect_type = usb_acpi_get_connect_type(handle, pld);
+ ACPI_FREE(pld);
+ }
+ return adev;
+}
+
+static struct acpi_device *
+usb_acpi_find_companion_for_device(struct usb_device *udev)
+{
+ struct acpi_device *adev;
+
+ if (!udev->parent)
+ return NULL;
+
+ /* root hub is only child (_ADR=0) under its parent, the HC */
+ adev = ACPI_COMPANION(udev->dev.parent);
+ return acpi_find_child_device(adev, 0, false);
+}
+
+
+static struct acpi_device *usb_acpi_find_companion(struct device *dev)
+{
/*
* In the ACPI DSDT table, only usb root hub and usb ports are
* acpi device nodes. The hierarchy like following.
@@ -158,66 +225,10 @@ static struct acpi_device *usb_acpi_find_companion(struct device *dev)
* So all binding process is divided into two parts. binding
* root hub and usb ports.
*/
- if (is_usb_device(dev)) {
- udev = to_usb_device(dev);
- if (udev->parent)
- return NULL;
-
- /* root hub is only child (_ADR=0) under its parent, the HC */
- adev = ACPI_COMPANION(dev->parent);
- return acpi_find_child_device(adev, 0, false);
- } else if (is_usb_port(dev)) {
- struct usb_port *port_dev = to_usb_port(dev);
- int port1 = port_dev->portnum;
- struct acpi_pld_info *pld;
- acpi_handle *handle;
- acpi_status status;
-
- /* Get the struct usb_device point of port's hub */
- udev = to_usb_device(dev->parent->parent);
-
- /*
- * The root hub ports' parent is the root hub. The non-root-hub
- * ports' parent is the parent hub port which the hub is
- * connected to.
- */
- if (!udev->parent) {
- struct usb_hcd *hcd = bus_to_hcd(udev->bus);
- int raw;
-
- raw = usb_hcd_find_raw_port_number(hcd, port1);
-
- adev = usb_acpi_find_port(ACPI_COMPANION(&udev->dev),
- raw);
-
- if (!adev)
- return NULL;
- } else {
- parent_handle =
- usb_get_hub_port_acpi_handle(udev->parent,
- udev->portnum);
- if (!parent_handle)
- return NULL;
-
- acpi_bus_get_device(parent_handle, &adev);
-
- adev = usb_acpi_find_port(adev, port1);
-
- if (!adev)
- return NULL;
- }
- handle = adev->handle;
- status = acpi_get_physical_device_location(handle, &pld);
- if (ACPI_FAILURE(status) || !pld)
- return adev;
-
- port_dev->location = USB_ACPI_LOCATION_VALID
- | pld->group_token << 8 | pld->group_position;
- port_dev->connect_type = usb_acpi_get_connect_type(handle, pld);
- ACPI_FREE(pld);
-
- return adev;
- }
+ if (is_usb_device(dev))
+ return usb_acpi_find_companion_for_device(to_usb_device(dev));
+ else if (is_usb_port(dev))
+ return usb_acpi_find_companion_for_port(to_usb_port(dev));
return NULL;
}
--
2.19.1.1215.g8438c0b245-goog
^ permalink raw reply related
* Re: [PATCH bpf-next] bpf: add read/write access to skb->tstamp from tc clsact progs
From: Eric Dumazet @ 2018-11-21 13:08 UTC (permalink / raw)
To: Alexei Starovoitov, Vlad Dumitrescu
Cc: Alexei Starovoitov, Daniel Borkmann, netdev, Eric Dumazet,
Willem de Bruijn
In-Reply-To: <20181121024040.sfqmmldjrsilwlit@ast-mbp>
On 11/20/2018 06:40 PM, Alexei Starovoitov wrote:
>
> looks good to me.
>
> Any particular reason you decided to disable it for cg_skb ?
> It seems to me the same EDT approach will work from
> cgroup-bpf skb hooks just as well and then we can have neat
> way of controlling traffic per-container instead of tc-clsbpf global.
> If you're already on cgroup v2 it will save you a lot of classifier
> cycles, since you'd be able to group apps by cgroup
> instead of relying on ip only.
Vlad first wrote a complete version, but we felt explaining the _why_
was probably harder.
No particular reason, other than having to write more tests perhaps.
^ permalink raw reply
* Re: [PATCH v2 13/14] nvmet-tcp: add NVMe over TCP target driver
From: Christoph Hellwig @ 2018-11-21 13:07 UTC (permalink / raw)
To: Sagi Grimberg
Cc: linux-nvme, linux-block, netdev, David S. Miller, Keith Busch,
Christoph Hellwig
In-Reply-To: <20181120030019.31738-15-sagi@grimberg.me>
> diff --git a/include/linux/nvme-tcp.h b/include/linux/nvme-tcp.h
> index 33c8afaf63bd..685780d1ed04 100644
> --- a/include/linux/nvme-tcp.h
> +++ b/include/linux/nvme-tcp.h
> @@ -11,6 +11,7 @@
>
> #define NVME_TCP_DISC_PORT 8009
> #define NVME_TCP_ADMIN_CCSZ SZ_8K
> +#define NVME_TCP_DIGEST_LENGTH 4
This should go into the previous patch.
^ permalink raw reply
* Re: [PATCH v2 11/14] nvme-fabrics: allow user passing data digest
From: Christoph Hellwig @ 2018-11-21 13:06 UTC (permalink / raw)
To: Sagi Grimberg
Cc: linux-nvme, linux-block, netdev, David S. Miller, Keith Busch,
Christoph Hellwig
In-Reply-To: <20181120030019.31738-13-sagi@grimberg.me>
On Mon, Nov 19, 2018 at 07:00:13PM -0800, Sagi Grimberg wrote:
> From: Sagi Grimberg <sagi@lightbitslabs.com>
>
> Data digest is a nvme-tcp specific feature, but nothing prevents other
> transports reusing the concept so do not associate with tcp transport
> solely.
>
> Signed-off-by: Sagi Grimberg <sagi@lightbitslabs.com>
Looks fine,
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [PATCH v2 10/14] nvme-fabrics: allow user passing header digest
From: Christoph Hellwig @ 2018-11-21 13:06 UTC (permalink / raw)
To: Sagi Grimberg
Cc: linux-nvme, linux-block, netdev, David S. Miller, Keith Busch,
Christoph Hellwig
In-Reply-To: <20181120030019.31738-12-sagi@grimberg.me>
On Mon, Nov 19, 2018 at 07:00:12PM -0800, Sagi Grimberg wrote:
> From: Sagi Grimberg <sagi@lightbitslabs.com>
>
> Header digest is a nvme-tcp specific feature, but nothing prevents other
> transports reusing the concept so do not associate with tcp transport
> solely.
>
> Signed-off-by: Sagi Grimberg <sagi@lightbitslabs.com>
Looks fine,
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [PATCH v2 09/14] nvmet: allow configfs tcp trtype configuration
From: Christoph Hellwig @ 2018-11-21 13:05 UTC (permalink / raw)
To: Sagi Grimberg
Cc: linux-nvme, linux-block, netdev, David S. Miller, Keith Busch,
Christoph Hellwig
In-Reply-To: <20181120030019.31738-11-sagi@grimberg.me>
On Mon, Nov 19, 2018 at 07:00:11PM -0800, Sagi Grimberg wrote:
> From: Sagi Grimberg <sagi@lightbitslabs.com>
>
> Reviewed-by: Max Gurtovoy <maxg@mellanox.com>
> Signed-off-by: Sagi Grimberg <sagi@lightbitslabs.com>
Looks fine,
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [PATCH v2 08/14] nvmet: Add install_queue callout
From: Christoph Hellwig @ 2018-11-21 13:05 UTC (permalink / raw)
To: Sagi Grimberg
Cc: linux-nvme, linux-block, netdev, David S. Miller, Keith Busch,
Christoph Hellwig
In-Reply-To: <20181120030019.31738-10-sagi@grimberg.me>
Looks fine,
Reviewed-by: Christoph Hellwig <hch@lst.de>
^ permalink raw reply
* Re: [Patch net-next 2/2] net: dump whole skb data in netdev_rx_csum_fault()
From: Eric Dumazet @ 2018-11-21 13:05 UTC (permalink / raw)
To: Cong Wang, netdev; +Cc: Herbert Xu, Eric Dumazet, David Miller
In-Reply-To: <20181121021309.6595-2-xiyou.wangcong@gmail.com>
On 11/20/2018 06:13 PM, Cong Wang wrote:
> Currently, we only dump a few selected skb fields in
> netdev_rx_csum_fault(). It is not suffient for debugging checksum
> fault. This patch introduces skb_dump() which dumps skb mac header,
> network header and its whole skb->data too.
>
> Cc: Herbert Xu <herbert@gondor.apana.org.au>
> Cc: Eric Dumazet <edumazet@google.com>
> Cc: David Miller <davem@davemloft.net>
> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
> ---
> + print_hex_dump(level, "skb data: ", DUMP_PREFIX_OFFSET, 16, 1,
> + skb->data, skb->len, false);
As I mentioned to David, we want all the bytes that were maybe already pulled
(skb->head starting point, not skb->data)
Also we will miss the trimmed bytes if there were padding data.
And it seems the various bugs we have are all tied to the pulled or trimmed bytes.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 07/14] nvme-core: add work elements to struct nvme_ctrl
From: Christoph Hellwig @ 2018-11-21 13:04 UTC (permalink / raw)
To: Sagi Grimberg
Cc: linux-nvme, linux-block, netdev, David S. Miller, Keith Busch,
Christoph Hellwig
In-Reply-To: <20181120030019.31738-9-sagi@grimberg.me>
On Mon, Nov 19, 2018 at 07:00:09PM -0800, Sagi Grimberg wrote:
> From: Sagi Grimberg <sagi@lightbitslabs.com>
>
> connect_work and err_work will be reused by nvme-tcp so
> share those in nvme_ctrl for rdma and fc to share.
As said before when you sent this invididually: I'd rather not move
struct members to the common struture until we actually start using
it there. So for now please add it to the containing TCP-specific
structure, although I'm looking forward to actually see code around
it consolidated eventually.
^ permalink raw reply
* linux-next: manual merge of the bpf-next tree with the net-next tree
From: Stephen Rothwell @ 2018-11-21 23:36 UTC (permalink / raw)
To: Daniel Borkmann, Alexei Starovoitov, Networking, David Miller
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Paolo Abeni,
Nikita V. Shirokov
[-- Attachment #1: Type: text/plain, Size: 1366 bytes --]
Hi all,
Today's linux-next merge of the bpf-next tree got a conflict in:
tools/testing/selftests/bpf/Makefile
between commit:
bd8e1afe6436 ("selftests: add dummy xdp test helper")
from the net-next tree and commit:
b1957c92eba5 ("bpf: adding tests for map_in_map helpber in libbpf")
from the bpf-next tree.
I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging. You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.
--
Cheers,
Stephen Rothwell
diff --cc tools/testing/selftests/bpf/Makefile
index 4a54236475ae,43157bd89165..000000000000
--- a/tools/testing/selftests/bpf/Makefile
+++ b/tools/testing/selftests/bpf/Makefile
@@@ -38,7 -39,7 +39,7 @@@ TEST_GEN_FILES = test_pkt_access.o test
get_cgroup_id_kern.o socket_cookie_prog.o test_select_reuseport_kern.o \
test_skb_cgroup_id_kern.o bpf_flow.o netcnt_prog.o \
test_sk_lookup_kern.o test_xdp_vlan.o test_queue_map.o test_stack_map.o \
- xdp_dummy.o
- test_map_in_map.o
++ xdp_dummy.o test_map_in_map.o
# Order correspond to 'make run_tests' order
TEST_PROGS := test_kmod.sh \
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 2/2] arm64/bpf: don't allocate BPF JIT programs in module memory
From: Daniel Borkmann @ 2018-11-21 23:20 UTC (permalink / raw)
To: Ard Biesheuvel, linux-arm-kernel
Cc: Alexei Starovoitov, Rick Edgecombe, Eric Dumazet, Jann Horn,
Kees Cook, Jessica Yu, Arnd Bergmann, Catalin Marinas,
Will Deacon, Mark Rutland, David S. Miller, linux-kernel, netdev
In-Reply-To: <20181121131733.14910-3-ard.biesheuvel@linaro.org>
On 11/21/2018 02:17 PM, Ard Biesheuvel wrote:
> The arm64 module region is a 128 MB region that is kept close to
> the core kernel, in order to ensure that relative branches are
> always in range. So using the same region for programs that do
> not have this restriction is wasteful, and preferably avoided.
>
> Now that the core BPF JIT code permits the alloc/free routines to
> be overridden, implement them by simple vmalloc_exec()/vfree()
> calls, which can be served from anywere. This also solves an
> issue under KASAN, where shadow memory is needlessly allocated for
> all BPF programs (which don't require KASAN shadow pages since
> they are not KASAN instrumented)
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> arch/arm64/net/bpf_jit_comp.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/arch/arm64/net/bpf_jit_comp.c b/arch/arm64/net/bpf_jit_comp.c
> index a6fdaea07c63..f91b7c157841 100644
> --- a/arch/arm64/net/bpf_jit_comp.c
> +++ b/arch/arm64/net/bpf_jit_comp.c
> @@ -940,3 +940,13 @@ struct bpf_prog *bpf_int_jit_compile(struct bpf_prog *prog)
> tmp : orig_prog);
> return prog;
> }
> +
> +void *bpf_jit_alloc_exec(unsigned long size)
> +{
> + return vmalloc_exec(size);
> +}
> +
> +void bpf_jit_free_exec(const void *addr)
> +{
> + return vfree(size);
> +}
Hmm, could you elaborate in the commit log on the potential performance
regression for JITed progs on arm64 after this change?
I think this change would also break JITing of BPF to BPF calls. You might
have the same issue as ppc64 folks where the offset might not fit into imm
anymore and would have to transfer it via fp->aux->func[off]->bpf_func
instead.
^ permalink raw reply
* Hello My Beloved One
From: Aisha Gaddafi @ 2018-11-21 12:44 UTC (permalink / raw)
Assalamu alaikum,
I came across your e-mail contact prior a private search while in need
of a
trusted person. My name is Mrs. Aisha Gaddafi, a single Mother and a
Widow
with three Children. I am the only biological Daughter of late Libyan
President (Late Colonel Muammar Gaddafi)I have a business Proposal for
you
worth $5.8Million dollars and I need mutual respect, trust, honesty,
transparency, adequate support and assistance, Hope to hear from you
for
more details.
regards
Mrs Aisha Gaddafi
^ permalink raw reply
* Re: Issue with RTL8111 NIC after upgrade to kernel 4.19
From: Marc Dionne @ 2018-11-21 23:13 UTC (permalink / raw)
To: hkallweit1
Cc: andrew, norbert.jurkeit, nic_swsd, Florian Fainelli, David Miller,
netdev, Linux Kernel Mailing List, michael.wiktowy, jcline
In-Reply-To: <a995b6f6-c5b1-877c-581c-39c0897e7703@gmail.com>
On Wed, Nov 21, 2018 at 6:28 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:
>
> On 21.11.2018 22:53, Marc Dionne wrote:
> > On Wed, Nov 21, 2018 at 4:52 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:
> >>
> >> On 21.11.2018 21:49, Heiner Kallweit wrote:
> >>> On 21.11.2018 21:32, Heiner Kallweit wrote:
> >>>> On 21.11.2018 21:20, Andrew Lunn wrote:
> >>>>>> request_module() is supposed to be synchronous, however after some
> >>>>>> reading this may not be 100% guaranteed. Maybe the module init
> >>>>>> function on some systems isn't finished yet when request_module()
> >>>>>> returns. As a result the genphy driver may be used instead of
> >>>>>> the PHY version-specific driver.
> >>>>>
> >>>>> Hi Heiner
> >>>>>
> >>>>> That would be true for all PHYs i think. We would of noticed this
> >>>>> problem with other systems using other PHY drivers.
> >>>>>
> >>>>> Andrew
> >>>>>
> >>>> It could be a timing issue affecting certain systems only. At least
> >>>> for now I don't have a good explanation why loading the module via
> >>>> request_module() and loading it upfront manually makes a difference.
> >>>>
> >>>> One affected user just reported the PHY to be a RTL8211B. This is
> >>>> what I expected, because this PHY crashes when writing to the MMD
> >>>> registers (the MMD registers are used otherwise by this PHY).
> >>>> See also commit 0231b1a074c6 ("net: phy: realtek: Use the dummy
> >>>> stubs for MMD register access for rtl8211b").
> >>>>
> >>>> Let's see whether the other affected systems use the same PHY
> >>>> version.
> >>>>
> >>> Next report is also about a RTL8211B and as I assumed:
> >>> - W/o manually loading the realtek module the genphy driver is used
> >>> and network fails.
> >>> - W/ manually loading the realtek module the proper RTL8211B PHY
> >>> driver is used and network works.
> >>>
> >>> So it seems that even after request_module() the PHY driver isn't
> >>> yet available when device and driver are matched.
> >>>
> >>> If further reports support this (pre-)analysis, then indeed it
> >>> seems to be a timing issue and a proper fix most likely is
> >>> difficult. As a workaround I could imagine to add a delay loop
> >>> after request_module() checking for a Realtek PHY driver via
> >>> driver_find(). When adding one small delay after this we should
> >>> be sufficiently sure that all Realtek PHY drivers are registered.
> >>>
> >> Uups, no. We talk about phylib here, not about the r8169 driver.
> >> So we need a different solution.
> >>
> >>>> Heiner
> >
> > Thanks for the explanation, better than my crude attempt at
> > understanding what was going on.
> >
> > If you have any proposed fixes or diagnostic patches based on current
> > mainline I can quickly compile and test them here on an affected
> > system. It doesn't fail consistently for me (as others have
> > reported), but that could be because it depends on the timing.
> >
>
> Thanks for the offer. Can you try the following diagnostic patch
> and check whether it helps?
>
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index 55202a0ac..84f417f8b 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -607,6 +607,8 @@ struct phy_device *phy_device_create(struct mii_bus *bus, int addr, int phy_id,
> */
> request_module(MDIO_MODULE_PREFIX MDIO_ID_FMT, MDIO_ID_ARGS(phy_id));
>
> + msleep(1000);
> +
> device_initialize(&mdiodev->dev);
>
> return dev;
I was not able to get it to fail with that extra delay; hard to be
100% sure but the network starts even when switching over from the
distro kernel after a boot where network failed to start.
There's a side issue that network startup is taking a full minute
longer than it should, but that's possibly unrelated.
Marc
^ permalink raw reply
* Re: [PATCH perf,bpf 5/5] perf util: generate bpf_prog_info_event for short living bpf programs
From: Alexei Starovoitov @ 2018-11-21 22:49 UTC (permalink / raw)
To: Song Liu, Alexei Starovoitov
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
ast@kernel.org, daniel@iogearbox.net, acme@kernel.org,
peterz@infradead.org, Kernel Team
In-Reply-To: <67063BF9-6237-4CF4-A0EB-0B14C5CA8A21@fb.com>
On 11/21/18 2:35 PM, Song Liu wrote:
>
>
>> On Nov 21, 2018, at 2:11 PM, Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>>
>> On Wed, Nov 21, 2018 at 11:55:02AM -0800, Song Liu wrote:
>>> This patch enables perf-record to listen to bpf_event and generate
>>> bpf_prog_info_event for bpf programs loaded and unloaded during
>>> perf-record run.
>>>
>>> To minimize latency between bpf_event and following bpf calls, separate
>>> mmap with watermark of 1 is created to process these vip events. Then
>>> a separate dummy event is attached to the special mmap. A separate thread
>>> is used to only poll bpf events.
>>>
>>> By default, perf-record will listen to bpf_event. Option no-bpf-event is
>>> added in case the user would opt out.
>>
>> I think only default perf-record for sampling should include it.
>> perf record -e for tracepoints, kprobes and anything else should imply no-bpf-event.
>>
>
> Maybe something like
>
> if (software_event && ! -g)
> no_bpf_event = true;
>
> ?
>
> This will allow attaching kprobe on bpf helper and see which bpf program
> calls it.
right. good point about -g (I assume you mean callgraph collection).
Indeed, if bpf progs unload before perf-report they won't be seen in
callgraphs too even for sw events, so we have to enable bpf_events
to see them.
^ permalink raw reply
* selftests/bpf: libbpf: object file doesn't contain bpf program
From: Naresh Kamboju @ 2018-11-21 12:04 UTC (permalink / raw)
To: open list:KERNEL SELFTEST FRAMEWORK, netdev; +Cc: brakmo, ast
The listed bpf test case failed due to,
libbpf: object file doesn't contain bpf program
We are cross compiling, installing selftests on device under test
and running tests by using run_kselftest.sh script file.
selftests: bpf: test_maps
libbpf: object file doesn't contain bpf program
Failed to load SK_SKB parse prog
not ok 1..3 selftests: bpf: test_maps [FAIL]
selftests: bpf: test_progs
libbpf: object file doesn't contain bpf program
libbpf: object file doesn't contain bpf program
libbpf: object file doesn't contain bpf program
libbpf: object file doesn't contain bpf program
libbpf: ./test_tcp_estats.o doesn't provide kernel version
libbpf: object file doesn't contain bpf program
selftests: bpf: test_tcpbpf_user
libbpf: object file doesn't contain bpf program
FAILED: load_bpf_file failed for: test_tcpbpf_kern.o
not ok 1..10 selftests: bpf: test_tcpbpf_user [FAIL]
selftests: bpf: test_tcpnotify_user
libbpf: object file doesn't contain bpf program
FAILED: load_bpf_file failed for: test_tcpnotify_kern.o
not ok 1..21 selftests: bpf: test_tcpnotify_user [FAIL]
selftests: bpf: test_flow_dissector.sh
bpffs not mounted. Mounting...
libbpf: object file doesn't contain bpf program
./flow_dissector_load: bpf_prog_load bpf_flow.o
selftests: test_flow_dissector [FAILED]
Do you see problem when running on target devices ?
Best regards
Naresh Kamboju
^ permalink raw reply
* Re: [PATCH perf,bpf 5/5] perf util: generate bpf_prog_info_event for short living bpf programs
From: Song Liu @ 2018-11-21 22:35 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
ast@kernel.org, daniel@iogearbox.net, acme@kernel.org,
peterz@infradead.org, Kernel Team
In-Reply-To: <20181121221145.2cxph7zv27x7lbg6@ast-mbp>
> On Nov 21, 2018, at 2:11 PM, Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
>
> On Wed, Nov 21, 2018 at 11:55:02AM -0800, Song Liu wrote:
>> This patch enables perf-record to listen to bpf_event and generate
>> bpf_prog_info_event for bpf programs loaded and unloaded during
>> perf-record run.
>>
>> To minimize latency between bpf_event and following bpf calls, separate
>> mmap with watermark of 1 is created to process these vip events. Then
>> a separate dummy event is attached to the special mmap. A separate thread
>> is used to only poll bpf events.
>>
>> By default, perf-record will listen to bpf_event. Option no-bpf-event is
>> added in case the user would opt out.
>
> I think only default perf-record for sampling should include it.
> perf record -e for tracepoints, kprobes and anything else should imply no-bpf-event.
>
Maybe something like
if (software_event && ! -g)
no_bpf_event = true;
?
This will allow attaching kprobe on bpf helper and see which bpf program
calls it.
Thanks,
Song
^ permalink raw reply
* Re: [PATCH perf,bpf 5/5] perf util: generate bpf_prog_info_event for short living bpf programs
From: Alexei Starovoitov @ 2018-11-21 22:11 UTC (permalink / raw)
To: Song Liu; +Cc: netdev, linux-kernel, ast, daniel, acme, peterz, kernel-team
In-Reply-To: <20181121195502.3259930-6-songliubraving@fb.com>
On Wed, Nov 21, 2018 at 11:55:02AM -0800, Song Liu wrote:
> This patch enables perf-record to listen to bpf_event and generate
> bpf_prog_info_event for bpf programs loaded and unloaded during
> perf-record run.
>
> To minimize latency between bpf_event and following bpf calls, separate
> mmap with watermark of 1 is created to process these vip events. Then
> a separate dummy event is attached to the special mmap. A separate thread
> is used to only poll bpf events.
>
> By default, perf-record will listen to bpf_event. Option no-bpf-event is
> added in case the user would opt out.
I think only default perf-record for sampling should include it.
perf record -e for tracepoints, kprobes and anything else should imply no-bpf-event.
^ permalink raw reply
* selftests/bpf :get_cgroup_id_user: File not found: /sys/kernel/debug/tracing/events/syscalls/sys_enter_nanosleep/id
From: Naresh Kamboju @ 2018-11-21 11:29 UTC (permalink / raw)
To: open list:KERNEL SELFTEST FRAMEWORK, netdev; +Cc: yhs, Daniel Borkmann
Kselftest bpf get_cgroup_id_user is failed on all devices.
selftests: bpf: get_cgroup_id_user
main:PASS:setup_cgroup_environment
main:PASS:create_and_get_cgroup
main:PASS:join_cgroup
main:PASS:bpf_prog_load
main:PASS:bpf_find_map
main:PASS:bpf_find_map
main:FAIL:open err -1 errno 2
not ok 1..15 selftests: bpf: get_cgroup_id_user [FAIL]
The strace output shows,
This expected file not found,
"/sys/kernel/debug/tracing/events/syscalls/sys_enter_nanosleep/id"
bpf(BPF_MAP_UPDATE_ELEM, {map_fd=5, key=0x7fff0c68c138,
value=0x7fff0c68c13c, flags=BPF_ANY}, 72) = 0
open(\"/sys/kernel/debug/tracing/events/syscalls/sys_enter_nanosleep/id\",
O_RDONLY) = -1 ENOENT (No such file or directory)
write(1, \"main:FAIL:open err -1 errno 2\n\", 30main:FAIL:open err -1 errno 2
Am I missing any pre-requirement ?
Best regards
Naresh Kamboju
^ permalink raw reply
* [PATCH v3 02/02] ravb: Clean up duplex handling
From: Magnus Damm @ 2018-11-21 11:21 UTC (permalink / raw)
To: netdev; +Cc: linux-renesas-soc, Magnus Damm, davem, sergei.shtylyov
In-Reply-To: <154279926877.10272.700833429936129422.sendpatchset@octo>
From: Magnus Damm <damm+renesas@opensource.se>
Since only full-duplex operation is supported by the
hardware, remove duplex handling code and keep the
register setting of ECMR.DM fixed at 1.
This updates the driver implementation to follow the
data sheet text "This bit should always be set to 1."
Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Applies on top of next-20181121
drivers/net/ethernet/renesas/ravb.h | 1 -
drivers/net/ethernet/renesas/ravb_main.c | 19 +------------------
2 files changed, 1 insertion(+), 19 deletions(-)
--- 0001/drivers/net/ethernet/renesas/ravb.h
+++ work/drivers/net/ethernet/renesas/ravb.h 2018-11-21 19:50:04.477121118 +0900
@@ -1032,7 +1032,6 @@ struct ravb_private {
phy_interface_t phy_interface;
int msg_enable;
int speed;
- int duplex;
int emac_irq;
enum ravb_chip_id chip_id;
int rx_irqs[NUM_RX_QUEUE];
--- 0002/drivers/net/ethernet/renesas/ravb_main.c
+++ work/drivers/net/ethernet/renesas/ravb_main.c 2018-11-21 19:50:04.479121223 +0900
@@ -82,13 +82,6 @@ static int ravb_config(struct net_device
return error;
}
-static void ravb_set_duplex(struct net_device *ndev)
-{
- struct ravb_private *priv = netdev_priv(ndev);
-
- ravb_modify(ndev, ECMR, ECMR_DM, priv->duplex ? ECMR_DM : 0);
-}
-
static void ravb_set_rate(struct net_device *ndev)
{
struct ravb_private *priv = netdev_priv(ndev);
@@ -406,13 +399,11 @@ error:
/* E-MAC init function */
static void ravb_emac_init(struct net_device *ndev)
{
- struct ravb_private *priv = netdev_priv(ndev);
-
/* Receive frame limit set register */
ravb_write(ndev, ndev->mtu + ETH_HLEN + VLAN_HLEN + ETH_FCS_LEN, RFLR);
/* EMAC Mode: PAUSE prohibition; Duplex; RX Checksum; TX; RX */
- ravb_write(ndev, ECMR_ZPF | (priv->duplex ? ECMR_DM : 0) |
+ ravb_write(ndev, ECMR_ZPF | ECMR_DM |
(ndev->features & NETIF_F_RXCSUM ? ECMR_RCSC : 0) |
ECMR_TE | ECMR_RE, ECMR);
@@ -995,12 +986,6 @@ static void ravb_adjust_link(struct net_
ravb_rcv_snd_disable(ndev);
if (phydev->link) {
- if (phydev->duplex != priv->duplex) {
- new_state = true;
- priv->duplex = phydev->duplex;
- ravb_set_duplex(ndev);
- }
-
if (phydev->speed != priv->speed) {
new_state = true;
priv->speed = phydev->speed;
@@ -1015,7 +1000,6 @@ static void ravb_adjust_link(struct net_
new_state = true;
priv->link = 0;
priv->speed = 0;
- priv->duplex = -1;
}
/* Enable TX and RX right over here, if E-MAC change is ignored */
@@ -1045,7 +1029,6 @@ static int ravb_phy_init(struct net_devi
priv->link = 0;
priv->speed = 0;
- priv->duplex = -1;
/* Try connecting to PHY */
pn = of_parse_phandle(np, "phy-handle", 0);
^ permalink raw reply
* [PATCH v3 01/02] ravb: Do not announce HDX as supported
From: Magnus Damm @ 2018-11-21 11:21 UTC (permalink / raw)
To: netdev; +Cc: linux-renesas-soc, Magnus Damm, davem, sergei.shtylyov
In-Reply-To: <154279926877.10272.700833429936129422.sendpatchset@octo>
From: Magnus Damm <damm+renesas@opensource.se>
According to the data sheet the Ethernet-AVB hardware in R-Car Gen3
and R-Car Gen2 SoCs do not support half duplex operation. So update
the driver to mark 100Mbit and 1Gbps HDX as unsupported.
Fixes: c156633f1353 ("Renesas Ethernet AVB driver proper")
Signed-off-by: Magnus Damm <damm+renesas@opensource.se>
Reviewed-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
---
Slightly reworked since V2 to make use of phy_remove_link_mode().
In case Sergei wants to opt-out from the Reviewed-by tag for V2 let us know.
Applies on top of next-20181121
drivers/net/ethernet/renesas/ravb_main.c | 4 ++++
1 file changed, 4 insertions(+)
--- 0001/drivers/net/ethernet/renesas/ravb_main.c
+++ work/drivers/net/ethernet/renesas/ravb_main.c 2018-11-21 19:47:58.165498803 +0900
@@ -1088,6 +1088,10 @@ static int ravb_phy_init(struct net_devi
phy_remove_link_mode(phydev, ETHTOOL_LINK_MODE_Pause_BIT);
phy_remove_link_mode(phydev, ETHTOOL_LINK_MODE_Asym_Pause_BIT);
+ /* Half Duplex is not supported */
+ phy_remove_link_mode(phydev, ETHTOOL_LINK_MODE_1000baseT_Half_BIT);
+ phy_remove_link_mode(phydev, ETHTOOL_LINK_MODE_100baseT_Half_BIT);
+
phy_attached_info(phydev);
return 0;
^ 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