* [PATCH v6 2/3] Bluetooth: btusb: Add out-of-band wakeup support
From: Rajat Jain @ 2017-01-25 18:34 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Marcel Holtmann, Gustavo Padovan,
Johan Hedberg, Amitkumar Karwar, Wei-Ning Huang, Xinming Hu,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA, Brian Norris,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Rajat Jain, rajatxjain-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <20170125183500.8292-1-rajatja-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Some onboard BT chips (e.g. Marvell 8997) contain a wakeup pin that
can be connected to a gpio on the CPU side, and can be used to wakeup
the host out-of-band. This can be useful in situations where the
in-band wakeup is not possible or not preferable (e.g. the in-band
wakeup may require the USB host controller to remain active, and
hence consuming more system power during system sleep).
The oob gpio interrupt to be used for wakeup on the CPU side, is
read from the device tree node, (using standard interrupt descriptors).
A devcie tree binding document is also added for the driver. The
compatible string is in compliance with
Documentation/devicetree/bindings/usb/usb-device.txt
Signed-off-by: Rajat Jain <rajatja-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Reviewed-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
---
v6: Remove the newlines in error statements ("\n")
v5: Move the call to pm_wakeup_event() to the begining of irq handler.
v4: Move the set_bit(BTUSB_OOB_WAKE_DISABLED,..) call to the beginning of
btusb_config_oob_wake()
v3: Add Brian's "Reviewed-by"
v2: * Use interrupt-names ("wakeup") instead of assuming first interrupt.
* Leave it on device tree to specify IRQ flags (level /edge triggered)
* Mark the device as non wakeable on exit.
Documentation/devicetree/bindings/net/btusb.txt | 40 ++++++++++++
drivers/bluetooth/btusb.c | 85 +++++++++++++++++++++++++
2 files changed, 125 insertions(+)
create mode 100644 Documentation/devicetree/bindings/net/btusb.txt
diff --git a/Documentation/devicetree/bindings/net/btusb.txt b/Documentation/devicetree/bindings/net/btusb.txt
new file mode 100644
index 000000000000..2c0355c85972
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/btusb.txt
@@ -0,0 +1,40 @@
+Generic Bluetooth controller over USB (btusb driver)
+---------------------------------------------------
+
+Required properties:
+
+ - compatible : should comply with the format "usbVID,PID" specified in
+ Documentation/devicetree/bindings/usb/usb-device.txt
+ At the time of writing, the only OF supported devices
+ (more may be added later) are:
+
+ "usb1286,204e" (Marvell 8997)
+
+Optional properties:
+
+ - interrupt-parent: phandle of the parent interrupt controller
+ - interrupt-names: (see below)
+ - interrupts : The interrupt specified by the name "wakeup" is the interrupt
+ that shall be used for out-of-band wake-on-bt. Driver will
+ request this interrupt for wakeup. During system suspend, the
+ irq will be enabled so that the bluetooth chip can wakeup host
+ platform out of band. During system resume, the irq will be
+ disabled to make sure unnecessary interrupt is not received.
+
+Example:
+
+Following example uses irq pin number 3 of gpio0 for out of band wake-on-bt:
+
+&usb_host1_ehci {
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mvl_bt1: bt@1 {
+ compatible = "usb1286,204e";
+ reg = <1>;
+ interrupt-parent = <&gpio0>;
+ interrupt-name = "wakeup";
+ interrupts = <3 IRQ_TYPE_LEVEL_LOW>;
+ };
+};
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index ce22cefceed1..0e7aed20b71b 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -24,6 +24,8 @@
#include <linux/module.h>
#include <linux/usb.h>
#include <linux/firmware.h>
+#include <linux/of_device.h>
+#include <linux/of_irq.h>
#include <asm/unaligned.h>
#include <net/bluetooth/bluetooth.h>
@@ -369,6 +371,7 @@ static const struct usb_device_id blacklist_table[] = {
#define BTUSB_BOOTING 9
#define BTUSB_RESET_RESUME 10
#define BTUSB_DIAG_RUNNING 11
+#define BTUSB_OOB_WAKE_DISABLED 12
struct btusb_data {
struct hci_dev *hdev;
@@ -416,6 +419,8 @@ struct btusb_data {
int (*recv_bulk)(struct btusb_data *data, void *buffer, int count);
int (*setup_on_usb)(struct hci_dev *hdev);
+
+ int oob_wake_irq; /* irq for out-of-band wake-on-bt */
};
static inline void btusb_free_frags(struct btusb_data *data)
@@ -2728,6 +2733,66 @@ static int btusb_bcm_set_diag(struct hci_dev *hdev, bool enable)
}
#endif
+#ifdef CONFIG_PM
+static irqreturn_t btusb_oob_wake_handler(int irq, void *priv)
+{
+ struct btusb_data *data = priv;
+
+ pm_wakeup_event(&data->udev->dev, 0);
+
+ /* Disable only if not already disabled (keep it balanced) */
+ if (!test_and_set_bit(BTUSB_OOB_WAKE_DISABLED, &data->flags)) {
+ disable_irq_nosync(irq);
+ disable_irq_wake(irq);
+ }
+ return IRQ_HANDLED;
+}
+
+static const struct of_device_id btusb_match_table[] = {
+ { .compatible = "usb1286,204e" },
+ { }
+};
+MODULE_DEVICE_TABLE(of, btusb_match_table);
+
+/* Use an oob wakeup pin? */
+static int btusb_config_oob_wake(struct hci_dev *hdev)
+{
+ struct btusb_data *data = hci_get_drvdata(hdev);
+ struct device *dev = &data->udev->dev;
+ int irq, ret;
+
+ set_bit(BTUSB_OOB_WAKE_DISABLED, &data->flags);
+
+ if (!of_match_device(btusb_match_table, dev))
+ return 0;
+
+ /* Move on if no IRQ specified */
+ irq = of_irq_get_byname(dev->of_node, "wakeup");
+ if (irq <= 0) {
+ bt_dev_dbg(hdev, "%s: no OOB Wakeup IRQ in DT", __func__);
+ return 0;
+ }
+
+ ret = devm_request_irq(&hdev->dev, irq, btusb_oob_wake_handler,
+ 0, "OOB Wake-on-BT", data);
+ if (ret) {
+ bt_dev_err(hdev, "%s: IRQ request failed", __func__);
+ return ret;
+ }
+
+ ret = device_init_wakeup(dev, true);
+ if (ret) {
+ bt_dev_err(hdev, "%s: failed to init_wakeup", __func__);
+ return ret;
+ }
+
+ data->oob_wake_irq = irq;
+ disable_irq(irq);
+ bt_dev_info(hdev, "OOB Wake-on-BT configured at IRQ %u", irq);
+ return 0;
+}
+#endif
+
static int btusb_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
@@ -2849,6 +2914,11 @@ static int btusb_probe(struct usb_interface *intf,
hdev->send = btusb_send_frame;
hdev->notify = btusb_notify;
+#ifdef CONFIG_PM
+ err = btusb_config_oob_wake(hdev);
+ if (err)
+ goto out_free_dev;
+#endif
if (id->driver_info & BTUSB_CW6622)
set_bit(HCI_QUIRK_BROKEN_STORED_LINK_KEY, &hdev->quirks);
@@ -3061,6 +3131,9 @@ static void btusb_disconnect(struct usb_interface *intf)
usb_driver_release_interface(&btusb_driver, data->isoc);
}
+ if (data->oob_wake_irq)
+ device_init_wakeup(&data->udev->dev, false);
+
hci_free_dev(hdev);
}
@@ -3089,6 +3162,12 @@ static int btusb_suspend(struct usb_interface *intf, pm_message_t message)
btusb_stop_traffic(data);
usb_kill_anchored_urbs(&data->tx_anchor);
+ if (data->oob_wake_irq && device_may_wakeup(&data->udev->dev)) {
+ clear_bit(BTUSB_OOB_WAKE_DISABLED, &data->flags);
+ enable_irq_wake(data->oob_wake_irq);
+ enable_irq(data->oob_wake_irq);
+ }
+
/* Optionally request a device reset on resume, but only when
* wakeups are disabled. If wakeups are enabled we assume the
* device will stay powered up throughout suspend.
@@ -3126,6 +3205,12 @@ static int btusb_resume(struct usb_interface *intf)
if (--data->suspend_count)
return 0;
+ /* Disable only if not already disabled (keep it balanced) */
+ if (!test_and_set_bit(BTUSB_OOB_WAKE_DISABLED, &data->flags)) {
+ disable_irq(data->oob_wake_irq);
+ disable_irq_wake(data->oob_wake_irq);
+ }
+
if (!test_bit(HCI_RUNNING, &hdev->flags))
goto done;
--
2.11.0.483.g087da7b7c-goog
^ permalink raw reply related
* [PATCH v6 1/3] Bluetooth: btusb: Use an error label for error paths
From: Rajat Jain @ 2017-01-25 18:34 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Marcel Holtmann, Gustavo Padovan,
Johan Hedberg, Amitkumar Karwar, Wei-Ning Huang, Xinming Hu,
netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA, Brian Norris,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: Rajat Jain, rajatxjain-Re5JQEeQqe8AvxtiuMwx3w
Use a label to remove the repetetive cleanup, for error cases.
Signed-off-by: Rajat Jain <rajatja-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
Reviewed-by: Brian Norris <briannorris-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>
---
v6: same as v5
v5: same as v4
v4: same as v3
v3: Added Brian's "Reviewed-by"
v2: same as v1
drivers/bluetooth/btusb.c | 19 +++++++++----------
1 file changed, 9 insertions(+), 10 deletions(-)
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 2f633df9f4e6..ce22cefceed1 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -2991,18 +2991,15 @@ static int btusb_probe(struct usb_interface *intf,
err = usb_set_interface(data->udev, 0, 0);
if (err < 0) {
BT_ERR("failed to set interface 0, alt 0 %d", err);
- hci_free_dev(hdev);
- return err;
+ goto out_free_dev;
}
}
if (data->isoc) {
err = usb_driver_claim_interface(&btusb_driver,
data->isoc, data);
- if (err < 0) {
- hci_free_dev(hdev);
- return err;
- }
+ if (err < 0)
+ goto out_free_dev;
}
#ifdef CONFIG_BT_HCIBTUSB_BCM
@@ -3016,14 +3013,16 @@ static int btusb_probe(struct usb_interface *intf,
#endif
err = hci_register_dev(hdev);
- if (err < 0) {
- hci_free_dev(hdev);
- return err;
- }
+ if (err < 0)
+ goto out_free_dev;
usb_set_intfdata(intf, data);
return 0;
+
+out_free_dev:
+ hci_free_dev(hdev);
+ return err;
}
static void btusb_disconnect(struct usb_interface *intf)
--
2.11.0.483.g087da7b7c-goog
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH net 0/3] bnxt_en: Fix RTNL lock usage in bnxt_sp_task().
From: David Miller @ 2017-01-25 18:27 UTC (permalink / raw)
To: michael.chan; +Cc: netdev
In-Reply-To: <1485330909-12037-1-git-send-email-michael.chan@broadcom.com>
From: Michael Chan <michael.chan@broadcom.com>
Date: Wed, 25 Jan 2017 02:55:06 -0500
> There are 2 function calls from bnxt_sp_task() that have buggy RTNL
> usage. These 2 functions take RTNL lock under some conditions, but
> some callers (such as open, ethtool) have already taken RTNL. These
> 3 patches fix the issue by making it clear that callers must take
> RTNL. If the caller is bnxt_sp_task() which does not automatically
> take RTNL, we add a common scheme for bnxt_sp_task() to call these
> functions properly under RTNL.
Series applied, thanks Michael.
You can sprinkle some ASSERT_RTNL(); in the functions that require
RTNL to be held if you like.
^ permalink raw reply
* Re: [PATCH net-next 0/2] Work around missing PHY prodcut ID in mv88e6390
From: David Miller @ 2017-01-25 18:25 UTC (permalink / raw)
To: andrew; +Cc: netdev, vivien.didelot, gregory.clement
In-Reply-To: <1485309314-23942-1-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Wed, 25 Jan 2017 02:55:12 +0100
> The internal PHYs of the MV88E6390 have a Marvell OUI, but the product
> ID is zero. Work around this by trapping reads to the ID, and if it is
> zero, return the MV88E6390 family ID.
Because of the ID masking issue, I am expecting a respin of this.
^ permalink raw reply
* Re: [PATCH net-next] r8152: fix the wrong spelling
From: David Miller @ 2017-01-25 18:24 UTC (permalink / raw)
To: hayeswang; +Cc: netdev, nic_swsd, linux-kernel, linux-usb
In-Reply-To: <1394712342-15778-241-Taiwan-albertk@realtek.com>
From: Hayes Wang <hayeswang@realtek.com>
Date: Wed, 25 Jan 2017 13:41:45 +0800
> Replace rumtime with runtime.
>
> Signed-off-by: Hayes Wang <hayeswang@realtek.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net] tcp: correct memory barrier usage in tcp_check_space()
From: David Miller @ 2017-01-25 18:23 UTC (permalink / raw)
To: eric.dumazet; +Cc: jbaron, netdev, oleg
In-Reply-To: <1485320017.16328.386.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 24 Jan 2017 20:53:37 -0800
> On Tue, 2017-01-24 at 21:49 -0500, Jason Baron wrote:
>> From: Jason Baron <jbaron@akamai.com>
>>
>> sock_reset_flag() maps to __clear_bit() not the atomic version clear_bit().
>> Thus, we need smp_mb(), smp_mb__after_atomic() is not sufficient.
>>
>> Fixes: 3c7151275c0c ("tcp: add memory barriers to write space paths")
>> Cc: Eric Dumazet <eric.dumazet@gmail.com>
>> Cc: Oleg Nesterov <oleg@redhat.com>
>> Signed-off-by: Jason Baron <jbaron@akamai.com>
>> ---
>> net/ipv4/tcp_input.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> Acked-by: Eric Dumazet <edumazet@google.com>
>
> I believe this would need also this for proper attribution.
>
> Reported-by: Oleg Nesterov <oleg@redhat.com>
Applied, thanks everyone.
^ permalink raw reply
* Re: [PATCH net-next] Doc: DT: bindings: net: dsa: marvell.txt: Tabification
From: David Miller @ 2017-01-25 18:20 UTC (permalink / raw)
To: andrew; +Cc: netdev, vivien.didelot
In-Reply-To: <1485308688-23670-1-git-send-email-andrew@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Wed, 25 Jan 2017 02:44:48 +0100
> Replace spaces with tabs. Fix indentation to be multiples of tabs, not
> a mixture or tabs and spaces.
>
> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
Applied, thanks for following up on this.
^ permalink raw reply
* Re: [PATCH net-next 0/3] BPF tracepoints
From: David Miller @ 2017-01-25 18:19 UTC (permalink / raw)
To: daniel; +Cc: ast, netdev, linux-kernel
In-Reply-To: <cover.1485306168.git.daniel@iogearbox.net>
From: Daniel Borkmann <daniel@iogearbox.net>
Date: Wed, 25 Jan 2017 02:28:15 +0100
> This set adds tracepoints to BPF for better introspection and
> debugging. The first two patches are prerequisite for the actual
> third patch that adds the tracepoints. I think the first two are
> small and straight forward enough that they could ideally go via
> net-next, but I'm also open to other suggestions on how to route
> them in case that's not applicable (it would reduce potential
> merge conflicts on BPF side, though). For details, please see
> individual patches.
Looks great, series applied, thanks Daniel.
^ permalink raw reply
* Re: [PATCH net-next] tcp: reduce skb overhead in selected places
From: David Miller @ 2017-01-25 18:17 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1485298656.16328.355.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 24 Jan 2017 14:57:36 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> tcp_add_backlog() can use skb_condense() helper to get better
> gains and less SKB_TRUESIZE() magic. This only happens when socket
> backlog has to be used.
>
> Some attacks involve specially crafted out of order tiny TCP packets,
> clogging the ofo queue of (many) sockets.
> Then later, expensive collapse happens, trying to copy all these skbs
> into single ones.
> This unfortunately does not work if each skb has no neighbor in TCP
> sequence order.
>
> By using skb_condense() if the skb could not be coalesced to a prior
> one, we defeat these kind of threats, potentially saving 4K per skb
> (or more, since this is one page fragment).
>
> A typical NAPI driver allocates gro packets with GRO_MAX_HEAD bytes
> in skb->head, meaning the copy done by skb_condense() is limited to
> about 200 bytes.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH 0/6 v3] kvmalloc
From: Alexei Starovoitov @ 2017-01-25 18:14 UTC (permalink / raw)
To: Michal Hocko
Cc: Andrew Morton, Vlastimil Babka, Mel Gorman, Johannes Weiner,
linux-mm, LKML, Daniel Borkmann, netdev@vger.kernel.org
On Wed, Jan 25, 2017 at 5:21 AM, Michal Hocko <mhocko@kernel.org> wrote:
> On Wed 25-01-17 14:10:06, Michal Hocko wrote:
>> On Tue 24-01-17 11:17:21, Alexei Starovoitov wrote:
>> > On Tue, Jan 24, 2017 at 04:17:52PM +0100, Michal Hocko wrote:
>> > > On Thu 12-01-17 16:37:11, Michal Hocko wrote:
>> > > > Hi,
>> > > > this has been previously posted as a single patch [1] but later on more
>> > > > built on top. It turned out that there are users who would like to have
>> > > > __GFP_REPEAT semantic. This is currently implemented for costly >64B
>> > > > requests. Doing the same for smaller requests would require to redefine
>> > > > __GFP_REPEAT semantic in the page allocator which is out of scope of
>> > > > this series.
>> > > >
>> > > > There are many open coded kmalloc with vmalloc fallback instances in
>> > > > the tree. Most of them are not careful enough or simply do not care
>> > > > about the underlying semantic of the kmalloc/page allocator which means
>> > > > that a) some vmalloc fallbacks are basically unreachable because the
>> > > > kmalloc part will keep retrying until it succeeds b) the page allocator
>> > > > can invoke a really disruptive steps like the OOM killer to move forward
>> > > > which doesn't sound appropriate when we consider that the vmalloc
>> > > > fallback is available.
>> > > >
>> > > > As it can be seen implementing kvmalloc requires quite an intimate
>> > > > knowledge if the page allocator and the memory reclaim internals which
>> > > > strongly suggests that a helper should be implemented in the memory
>> > > > subsystem proper.
>> > > >
>> > > > Most callers I could find have been converted to use the helper instead.
>> > > > This is patch 5. There are some more relying on __GFP_REPEAT in the
>> > > > networking stack which I have converted as well but considering we do
>> > > > not have a support for __GFP_REPEAT for requests smaller than 64kB I
>> > > > have marked it RFC.
>> > >
>> > > Are there any more comments? I would really appreciate to hear from
>> > > networking folks before I resubmit the series.
>> >
>> > while this patchset was baking the bpf side switched to use bpf_map_area_alloc()
>> > which fixes the issue with missing __GFP_NORETRY that we had to fix quickly.
>> > See commit d407bd25a204 ("bpf: don't trigger OOM killer under pressure with map alloc")
>> > it covers all kmalloc/vmalloc pairs instead of just one place as in this set.
>> > So please rebase and switch bpf_map_area_alloc() to use kvmalloc().
>>
>> OK, will do. Thanks for the heads up.
>
> Just for the record, I will fold the following into the patch 1
> ---
> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index 19b6129eab23..8697f43cf93c 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -53,21 +53,7 @@ void bpf_register_map_type(struct bpf_map_type_list *tl)
>
> void *bpf_map_area_alloc(size_t size)
> {
> - /* We definitely need __GFP_NORETRY, so OOM killer doesn't
> - * trigger under memory pressure as we really just want to
> - * fail instead.
> - */
> - const gfp_t flags = __GFP_NOWARN | __GFP_NORETRY | __GFP_ZERO;
> - void *area;
> -
> - if (size <= (PAGE_SIZE << PAGE_ALLOC_COSTLY_ORDER)) {
> - area = kmalloc(size, GFP_USER | flags);
> - if (area != NULL)
> - return area;
> - }
> -
> - return __vmalloc(size, GFP_KERNEL | __GFP_HIGHMEM | flags,
> - PAGE_KERNEL);
> + return kvzalloc(size, GFP_USER);
> }
>
> void bpf_map_area_free(void *area)
Looks fine by me.
Daniel, thoughts?
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: dsa: mv88e6xxx: Workaround missing PHY ID on mv88e6390
From: Vivien Didelot @ 2017-01-25 18:03 UTC (permalink / raw)
To: Gregory CLEMENT, Andrew Lunn; +Cc: David Miller, netdev
In-Reply-To: <87o9yvyqwr.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>
Andrew,
Vivien Didelot <vivien.didelot@savoirfairelinux.com> writes:
> Since several chips have this issue, we can introduce a u16 physid2_mask
> member in the mv88e6xxx_info structure and move the check in
> mv88e6xxx_phy_read() so that the logic of device (as in Global2) helpers
> are not affected by such (necessary) hack. Something like:
>
> static int mv88e6xxx_phy_read(struct mv88e6xxx_chip *chip, int phy,
> int reg, u16 *val)
> {
> ...
>
> err = chip->info->ops->phy_read(chip, bus, addr, reg, val);
> if (err)
> return err;
>
> if (reg == MII_PHYSID2 && chip->info->physid2_mask) {
> /* Some internal PHYs don't have a model number,
> * so return the switch family model number directly.
> */
> if (!(*val & chip->info->physid2_mask))
> *val |= chip->info->prod_num;
if (reg == MII_PHYSID2 && (*val & 0xfff0) == 0)
*val |= chip->info->prod_num << 4;
then. Do you agree?
> }
>
> return 0;
> }
Thanks,
Vivien
^ permalink raw reply
* Re: [PATCH net] net: dsa: Bring back device detaching in dsa_slave_suspend()
From: Andrew Lunn @ 2017-01-25 18:00 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, Vivien Didelot, David S. Miller, open list
In-Reply-To: <20170125171041.21442-1-f.fainelli@gmail.com>
On Wed, Jan 25, 2017 at 09:10:41AM -0800, Florian Fainelli wrote:
> Commit 448b4482c671 ("net: dsa: Add lockdep class to tx queues to avoid
> lockdep splat") removed the netif_device_detach() call done in
> dsa_slave_suspend() which is necessary, and paired with a corresponding
> netif_device_attach(), bring it back.
>
> Fixes: 448b4482c671 ("net: dsa: Add lockdep class to tx queues to avoid lockdep splat")
> Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Sorry for accidentally removing it.
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: dsa: mv88e6xxx: Workaround missing PHY ID on mv88e6390
From: Andrew Lunn @ 2017-01-25 18:00 UTC (permalink / raw)
To: Vivien Didelot; +Cc: Gregory CLEMENT, David Miller, netdev
In-Reply-To: <87o9yvyqwr.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>
> Since several chips have this issue, we can introduce a u16 physid2_mask
> member in the mv88e6xxx_info structure and move the check in
> mv88e6xxx_phy_read() so that the logic of device (as in Global2) helpers
> are not affected by such (necessary) hack. Something like:
>
> static int mv88e6xxx_phy_read(struct mv88e6xxx_chip *chip, int phy,
> int reg, u16 *val)
> {
> ...
>
> err = chip->info->ops->phy_read(chip, bus, addr, reg, val);
> if (err)
> return err;
>
> if (reg == MII_PHYSID2 && chip->info->physid2_mask) {
> /* Some internal PHYs don't have a model number,
> * so return the switch family model number directly.
> */
> if (!(*val & chip->info->physid2_mask))
Hi Vivien
I don't see the need to have per switch masks. Lets just hard code it
to ignore the lower 4 bits.
> *val |= chip->info->prod_num;
and this is not good. I deliberately picked the family num, not the
product num. Otherwise for the 6390 family, we have 6 different PHY
IDs. And two more for Gregorys two switches.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 3/3] net/tcp-fastopen: Add new API support
From: Willy Tarreau @ 2017-01-25 17:54 UTC (permalink / raw)
To: David Miller; +Cc: tracywwnj, eric.dumazet, netdev, edumazet, ycheng, weiwan
In-Reply-To: <20170125.122205.9460825196595773.davem@davemloft.net>
On Wed, Jan 25, 2017 at 12:22:05PM -0500, David Miller wrote:
> From: Wei Wang <tracywwnj@gmail.com>
> Date: Wed, 25 Jan 2017 09:15:34 -0800
>
> > Looks like you sent a separate patch on top of this patch series to
> > address double connect(). Then I think this patch series should be
> > good to go.
>
> Indeed, Willy please give some kind of ACK.
Yes sorry David, for me it's OK. If Wei runs his whole series of tests
on it again, it should be perfect.
thanks,
Willy
^ permalink raw reply
* Re: [PATCH net-next 3/3] net/tcp-fastopen: Add new API support
From: Willy Tarreau @ 2017-01-25 17:53 UTC (permalink / raw)
To: Wei Wang
Cc: Eric Dumazet, Linux Kernel Network Developers, David Miller,
Eric Dumazet, Yuchung Cheng, Wei Wang
In-Reply-To: <CAC15z3izWNh7th_yxA_a90vgLnU5XzVDm6vyojq3cMDgQZ71YA@mail.gmail.com>
Hi Wei,
On Wed, Jan 25, 2017 at 09:15:34AM -0800, Wei Wang wrote:
> Willy,
>
> Looks like you sent a separate patch on top of this patch series to address
> double connect().
Yes, sorry, I wanted to reply to this thread after the git-send-email
and got caught immediately after :-)
So as suggested by Eric in order to make the review easier, it was done
on top of your series.
> Then I think this patch series should be good to go.
> I will get your patch tested with our TFO test cases.
I think so as well. Thanks for running the tests. On my side I could fix
the haproxy bug which triggered this, and could verify the the whole
series works fine both with and without the haproxy fix. So I think we're
good now.
Thanks,
Willy
^ permalink raw reply
* Re: [pull request][net-next 00/12] Mellanox mlx5 updates 2017-01-24
From: David Miller @ 2017-01-25 17:52 UTC (permalink / raw)
To: saeedm; +Cc: netdev, ogerlitz
In-Reply-To: <20170124201652.2920-1-saeedm@mellanox.com>
From: Saeed Mahameed <saeedm@mellanox.com>
Date: Tue, 24 Jan 2017 22:16:40 +0200
> This pull request includes one new feature to support offloading IPv6
> tunnels in switchdev mode, in addition to some small mlx5 updates.
> Details are down bleow.
>
> Please pull and let me know if there's any problem.
Pulled, thanks a lot.
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: dsa: mv88e6xxx: Workaround missing PHY ID on mv88e6390
From: Andrew Lunn @ 2017-01-25 17:52 UTC (permalink / raw)
To: Gregory CLEMENT; +Cc: David Miller, netdev, Vivien Didelot
In-Reply-To: <87sho7123x.fsf@free-electrons.com>
> I tested this series on the Topaz switch but it failed because while I
> said we read 0x1410C00 actually we read 0x01410C01. With the
> MARVELL_PHY_ID_MASK we mask the 4 lower bits so that's why in my patch
> "phy: marvell: Add support for the PHY embedded in the topaz switch" I
> used the 0x01410C00 value for MARVELL_PHY_ID_88E6141.
O.K. The lower 4 bits seem to be the silicon revision. Marvells own
SDK ignores those bits. So lets do the same here, use
MARVELL_PHY_ID_MASK.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: dsa: mv88e6xxx: Workaround missing PHY ID on mv88e6390
From: Florian Fainelli @ 2017-01-25 17:51 UTC (permalink / raw)
To: Gregory CLEMENT, Andrew Lunn; +Cc: David Miller, netdev, Vivien Didelot
In-Reply-To: <87sho7123x.fsf@free-electrons.com>
On 01/25/2017 09:27 AM, Gregory CLEMENT wrote:
> Hi Andrew,
>
> On mer., janv. 25 2017, Andrew Lunn <andrew@lunn.ch> wrote:
>
>> The internal PHYs of the mv88e6390 do not have a model ID. Trap any
>> calls to the ID register, and if it is zero, return the ID for the
>> mv88e6390. The Marvell PHY driver can then bind to this ID.
>>
>> Signed-off-by: Andrew Lunn <andrew@lunn.ch>
>> Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
>> ---
>> drivers/net/dsa/mv88e6xxx/global2.c | 16 +++++++++++++++-
>> 1 file changed, 15 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/dsa/mv88e6xxx/global2.c b/drivers/net/dsa/mv88e6xxx/global2.c
>> index 353e26bea3c3..521a5511bd5f 100644
>> --- a/drivers/net/dsa/mv88e6xxx/global2.c
>> +++ b/drivers/net/dsa/mv88e6xxx/global2.c
>> @@ -520,7 +520,21 @@ int mv88e6xxx_g2_smi_phy_read(struct mv88e6xxx_chip *chip,
>> if (err)
>> return err;
>>
>> - return mv88e6xxx_g2_read(chip, GLOBAL2_SMI_PHY_DATA, val);
>> + err = mv88e6xxx_g2_read(chip, GLOBAL2_SMI_PHY_DATA, val);
>> + if (err)
>> + return err;
>> +
>> + if (reg == MII_PHYSID2) {
>> + /* The mv88e6390 internal PHYS don't have a model number.
>> + * Use the switch family model number instead.
>> + */
>> + if (!(*val & 0x3ff)) {
>
> I tested this series on the Topaz switch but it failed because while I
> said we read 0x1410C00 actually we read 0x01410C01. With the
> MARVELL_PHY_ID_MASK we mask the 4 lower bits so that's why in my patch
> "phy: marvell: Add support for the PHY embedded in the topaz switch" I
> used the 0x01410C00 value for MARVELL_PHY_ID_88E6141.
>
> However with the mask you use it doesn't work.
>
> So this mask should be changed to 0x3f0 for the Topaz. Actually 0x3fe
> would be enough but it seems more logical to use the same mask that for
> MARVELL_PHY_ID_MASK.
>
> We could either use the same mask for both family and still use 6390 as
> they seem compatible or we use two different families based on the lower
> bit.
By convention, the lower 4 bits are used to carry revision information,
which is why most drivers use 0xxxxx_fff0, can you try to use that here
for the PHY mask value?
--
Florian
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: dsa: mv88e6xxx: Workaround missing PHY ID on mv88e6390
From: Vivien Didelot @ 2017-01-25 17:45 UTC (permalink / raw)
To: Gregory CLEMENT, Andrew Lunn; +Cc: David Miller, netdev
In-Reply-To: <87sho7123x.fsf@free-electrons.com>
Hi Gregory, Andrew,
Gregory CLEMENT <gregory.clement@free-electrons.com> writes:
>> + if (reg == MII_PHYSID2) {
>> + /* The mv88e6390 internal PHYS don't have a model number.
>> + * Use the switch family model number instead.
>> + */
>> + if (!(*val & 0x3ff)) {
>
> I tested this series on the Topaz switch but it failed because while I
> said we read 0x1410C00 actually we read 0x01410C01. With the
> MARVELL_PHY_ID_MASK we mask the 4 lower bits so that's why in my patch
> "phy: marvell: Add support for the PHY embedded in the topaz switch" I
> used the 0x01410C00 value for MARVELL_PHY_ID_88E6141.
>
> However with the mask you use it doesn't work.
>
> So this mask should be changed to 0x3f0 for the Topaz. Actually 0x3fe
> would be enough but it seems more logical to use the same mask that for
> MARVELL_PHY_ID_MASK.
>
> We could either use the same mask for both family and still use 6390 as
> they seem compatible or we use two different families based on the lower
> bit.
Since several chips have this issue, we can introduce a u16 physid2_mask
member in the mv88e6xxx_info structure and move the check in
mv88e6xxx_phy_read() so that the logic of device (as in Global2) helpers
are not affected by such (necessary) hack. Something like:
static int mv88e6xxx_phy_read(struct mv88e6xxx_chip *chip, int phy,
int reg, u16 *val)
{
...
err = chip->info->ops->phy_read(chip, bus, addr, reg, val);
if (err)
return err;
if (reg == MII_PHYSID2 && chip->info->physid2_mask) {
/* Some internal PHYs don't have a model number,
* so return the switch family model number directly.
*/
if (!(*val & chip->info->physid2_mask))
*val |= chip->info->prod_num;
}
return 0;
}
Thanks,
Vivien
^ permalink raw reply
* Re: [PATCH RFC net-next] packet: always ensure that we pass hard_header_len bytes in skb_headlen() to the driver
From: David Miller @ 2017-01-25 17:45 UTC (permalink / raw)
To: sowmini.varadhan; +Cc: netdev
In-Reply-To: <1485274309-201670-1-git-send-email-sowmini.varadhan@oracle.com>
From: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Date: Tue, 24 Jan 2017 08:11:49 -0800
> @@ -2685,21 +2685,22 @@ static inline int dev_parse_header(const struct sk_buff *skb,
> }
>
> /* ll_header must have at least hard_header_len allocated */
> -static inline bool dev_validate_header(const struct net_device *dev,
> +static inline int dev_validate_header(const struct net_device *dev,
> char *ll_header, int len)
> {
> if (likely(len >= dev->hard_header_len))
> - return true;
> + return len;
>
> if (capable(CAP_SYS_RAWIO)) {
> memset(ll_header + len, 0, dev->hard_header_len - len);
> - return true;
> + return dev->hard_header_len;
> }
>
> if (dev->header_ops && dev->header_ops->validate)
> - return dev->header_ops->validate(ll_header, len);
> + if (!dev->header_ops->validate(ll_header, len))
> + return -1;
>
> - return false;
> + return dev->hard_header_len;
> }
>
> typedef int gifconf_func_t(struct net_device * dev, char __user * bufptr, int len);
This mostly looks good. But I'm not so sure you handle the variable length header
case properly. That's why we have the header_ops->validate() callback, to accomodate
that.
In the variable length case, you'll end up having to return something other than
just hard_header_len. Probably you'll need to make header_ops->validate() return
that length.
^ permalink raw reply
* Re: [patch net-next] tipc: uninitialized return code in tipc_setsockopt()
From: David Miller @ 2017-01-25 17:41 UTC (permalink / raw)
To: dan.carpenter
Cc: jon.maloy, ying.xue, netdev, tipc-discussion, kernel-janitors
In-Reply-To: <20170124094935.GA19984@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Tue, 24 Jan 2017 12:49:35 +0300
> We shuffled some code around and added some new case statements here and
> now "res" isn't initialized on all paths.
>
> Fixes: 01fd12bb189a ("tipc: make replicast a user selectable option")
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied, thanks Dan.
^ permalink raw reply
* Re: [PATCH net-next v7 1/1] net sched actions: Add support for user cookies
From: David Miller @ 2017-01-25 17:38 UTC (permalink / raw)
To: jhs
Cc: netdev, jiri, paulb, john.fastabend, simon.horman, mrv, hadarh,
ogerlitz, roid, xiyou.wangcong, daniel
In-Reply-To: <1485259361-16860-1-git-send-email-jhs@emojatatu.com>
From: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Tue, 24 Jan 2017 07:02:41 -0500
> Introduce optional 128-bit action cookie.
Applied, but like Jiri I think you can use one buffer instead of two
to store the user's cookie data.
Thanks.
^ permalink raw reply
* Re: [PATCH] net: ethernet: mvneta: add support for 2.5G DRSGMII mode
From: David Miller @ 2017-01-25 17:38 UTC (permalink / raw)
To: jlu-bIcnvbaLZ9MEGnE8C9+IrQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
robh+dt-DgEjT+Ai2ygdnm+yROfE0A, mark.rutland-5wv7dgnIgG8,
thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8,
f.fainelli-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <20170123142206.5390-1-jlu-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
From: Jan Luebbe <jlu-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Date: Mon, 23 Jan 2017 15:22:06 +0100
> The Marvell MVNETA Ethernet controller supports a 2.5 Gbps SGMII mode
> called DRSGMII.
>
> This patch adds a corresponding phy-mode string 'drsgmii' and parses it
> from DT. The MVNETA then configures the SERDES protocol value
> accordingly.
>
> It was successfully tested on a MV78460 connected to a FPGA.
>
> Signed-off-by: Jan Luebbe <jlu-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
I still haven't seen a sufficient explanation as to why this change
works without any explicit MAC programming changes to this driver.
That really needs to be explained before I will apply this patch.
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v4] net: ethernet: faraday: To support device tree usage.
From: David Miller @ 2017-01-25 17:34 UTC (permalink / raw)
To: green.hu
Cc: netdev, devicetree, andrew, arnd, jiri, linux-kernel, f.fainelli,
robh+dt, mark.rutland
In-Reply-To: <20170124084606.GA11764@app09>
From: Greentime Hu <green.hu@gmail.com>
Date: Tue, 24 Jan 2017 16:46:14 +0800
> We also use the same binding document to describe the same faraday ethernet
> controller and add faraday to vendor-prefixes.txt.
>
> Signed-off-by: Greentime Hu <green.hu@gmail.com>
> ---
> Changes in v4:
> - Use the same binding document to describe the same faraday ethernet controller and add faraday to vendor-prefixes.txt.
> Changes in v3:
> - Nothing changed in this patch but I have committed andestech to vendor-prefixes.txt.
> Changes in v2:
> - Change atmac100_of_ids to ftmac100_of_ids
>
> ---
> .../net/{moxa,moxart-mac.txt => faraday,ftmac.txt} | 7 +++++--
> .../devicetree/bindings/vendor-prefixes.txt | 1 +
> drivers/net/ethernet/faraday/ftmac100.c | 7 +++++++
> 3 files changed, 13 insertions(+), 2 deletions(-)
> rename Documentation/devicetree/bindings/net/{moxa,moxart-mac.txt => faraday,ftmac.txt} (68%)
>
> diff --git a/Documentation/devicetree/bindings/net/moxa,moxart-mac.txt b/Documentation/devicetree/bindings/net/faraday,ftmac.txt
> similarity index 68%
> rename from Documentation/devicetree/bindings/net/moxa,moxart-mac.txt
> rename to Documentation/devicetree/bindings/net/faraday,ftmac.txt
Why are you renaming the MOXA binding file instead of adding a completely new one
for faraday? The MOXA one should stick around, I don't see a justification for
removing it.
^ permalink raw reply
* Re: [PATCH net] sctp: sctp gso should set feature with NETIF_F_SG when calling skb_segment
From: David Miller @ 2017-01-25 17:29 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, nhorman
In-Reply-To: <7b4d081c051650e706ffda360fdfbd4baaa1a317.1485237916.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Tue, 24 Jan 2017 14:05:16 +0800
> Now sctp gso puts segments into skb's frag_list, then processes these
> segments in skb_segment. But skb_segment handles them only when gs is
> enabled, as it's in the same branch with skb's frags.
>
> Although almost all the NICs support sg other than some old ones, but
> since commit 1e16aa3ddf86 ("net: gso: use feature flag argument in all
> protocol gso handlers"), features &= skb->dev->hw_enc_features, and
> xfrm_output_gso call skb_segment with features = 0, which means sctp
> gso would call skb_segment with sg = 0, and skb_segment would not work
> as expected.
>
> This patch is to fix it by setting features param with NETIF_F_SG when
> calling skb_segment so that it can go the right branch to process the
> skb's frag_list.
>
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
Applied, thanks.
^ 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