* Re: [PATCH 0/2] More ethtool support and BGX configuration changes
From: David Miller @ 2017-01-25 19:43 UTC (permalink / raw)
To: sunil.kovvuri; +Cc: netdev, linux-kernel, linux-arm-kernel, sgoutham
In-Reply-To: <1485345984-28163-1-git-send-email-sunil.kovvuri@gmail.com>
From: sunil.kovvuri@gmail.com
Date: Wed, 25 Jan 2017 17:36:22 +0530
> These patches adds support to set queue sizes from ethtool and changes
> the way serdes lane configuration is done by BGX driver on 81/83xx
> platforms.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH v2 0/3] net: phy: leds: Fix truncated LED trigger names and crashes
From: David Miller @ 2017-01-25 19:40 UTC (permalink / raw)
To: geert+renesas
Cc: f.fainelli, zach.brown, volodymyr.bendiuga, andrew, magnus.oberg,
netdev, linux-renesas-soc, linux-kernel
In-Reply-To: <1485340790-10785-1-git-send-email-geert+renesas@glider.be>
From: Geert Uytterhoeven <geert+renesas@glider.be>
Date: Wed, 25 Jan 2017 11:39:47 +0100
> I started seeing crashes during s2ram and poweroff on all my ARM boards,
> like:
>
> Unable to handle kernel NULL pointer dereference at virtual address 00000000
> ...
> [<c04116d4>] (__list_del_entry_valid) from [<c05e8948>] (led_trigger_unregister+0x34/0xcc)
> [<c05e8948>] (led_trigger_unregister) from [<c05336c4>] (phy_led_triggers_unregister+0x28/0x34)
> [<c05336c4>] (phy_led_triggers_unregister) from [<c0531d44>] (phy_detach+0x30/0x74)
> [<c0531d44>] (phy_detach) from [<c0538bdc>] (sh_eth_close+0x64/0x9c)
> [<c0538bdc>] (sh_eth_close) from [<c04d4ce0>] (dpm_run_callback+0x48/0xc8)
>
> or:
>
> list_del corruption. prev->next should be dede6540, but was 2e323931
> ------------[ cut here ]------------
> kernel BUG at lib/list_debug.c:52!
> ...
> [<c02f6d70>] (__list_del_entry_valid) from [<c0425168>] (led_trigger_unregister+0x34/0xcc)
> [<c0425168>] (led_trigger_unregister) from [<c03a05a0>] (phy_led_triggers_unregister+0x28/0x34)
> [<c03a05a0>] (phy_led_triggers_unregister) from [<c039ec04>] (phy_detach+0x30/0x74)
> [<c039ec04>] (phy_detach) from [<c03a4fc0>] (sh_eth_close+0x6c/0xa4)
> [<c03a4fc0>] (sh_eth_close) from [<c0483234>] (__dev_close_many+0xac/0xd0)
>
> As the only clue was a kernel message like
>
> sh-eth ee700000.ethernet eth0: No phy led trigger registered for speed(100)
>
> I had to bisected this, leading to commit 4567d686f5c6d955 ("phy:
> increase size of MII_BUS_ID_SIZE and bus_id"). Reverting that commit
> fixed the issue.
>
> More investigation revealed the crashes are due to the combination of
> two things:
> - Truncated LED trigger names, leading to duplicate names, and
> registration failures,
> - Bad error handling in case of registration failures.
>
> Both are fixed by this patch series.
Thanks for tracking this down and fixing it.
Series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: dsa: mv88e6xxx: Workaround missing PHY ID on mv88e6390
From: Vivien Didelot @ 2017-01-25 19:37 UTC (permalink / raw)
To: Andrew Lunn; +Cc: Gregory CLEMENT, David Miller, netdev
In-Reply-To: <20170125193040.GE6611@lunn.ch>
Hi Andrew,
Andrew Lunn <andrew@lunn.ch> writes:
>> if (reg == MII_PHYSID2 && (*val & 0xfff0) == 0)
>
> This should be 0x3f0. There are 10 bits for the device model, of which
> Marvell uses the lowest 4 for version.
>
>> *val |= chip->info->prod_num << 4;
>
> #define PORT_SWITCH_ID_PROD_NUM_6190 0x190
> #define PORT_SWITCH_ID_PROD_NUM_6190X 0x0a0
> #define PORT_SWITCH_ID_PROD_NUM_6191 0x191
> #define PORT_SWITCH_ID_PROD_NUM_6290 0x290
> #define PORT_SWITCH_ID_PROD_NUM_6390 0x390
> #define PORT_SWITCH_ID_PROD_NUM_6390X 0x0a1
>
> That still gives us 6 different PHY IDs, and the shift will cause is
> to modify the OUI, so it is no longer a Marvell OUI.
OK, this is fine with the Marvell mask then. Can you move the check in
the higher mv88e6xxx_phy_read() function when you respin please?
Thanks!
Vivien
^ permalink raw reply
* Re: [PATCH 2/2] net-next: ethernet: mediatek: change the compatible string
From: David Miller @ 2017-01-25 19:36 UTC (permalink / raw)
To: john-Pj+rj9U5foFAfugRpC6u6w
Cc: robh+dt-DgEjT+Ai2ygdnm+yROfE0A,
matthias.bgg-Re5JQEeQqe8AvxtiuMwx3w,
netdev-u79uwXL29TY76Z2rM5mHXA, sean.wang-NuS5LvNUpcJWk0Htik3J/w,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-mediatek-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1485332455-34743-2-git-send-email-john-Pj+rj9U5foFAfugRpC6u6w@public.gmane.org>
From: John Crispin <john-Pj+rj9U5foFAfugRpC6u6w@public.gmane.org>
Date: Wed, 25 Jan 2017 09:20:55 +0100
> When the binding was defined, I was not aware that mt2701 was an earlier
> version of the SoC. For sake of consistency, the ethernet driver should
> use mt2701 inside the compat string as this is the earliest SoC with the
> ethernet core.
>
> The ethernet driver is currently of no real use until we finish and
> upstream the DSA driver. There are no users of this binding yet. It should
> be safe to fix this now before it is too late and we need to provide
> backward compatibility for the mt7623-eth compat string.
>
> Reported-by: Sean Wang <sean.wang-NuS5LvNUpcJWk0Htik3J/w@public.gmane.org>
> Signed-off-by: John Crispin <john-Pj+rj9U5foFAfugRpC6u6w@public.gmane.org>
Applied.
--
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 1/2] Documentation: devicetree: change the mediatek ethernet compatible string
From: David Miller @ 2017-01-25 19:36 UTC (permalink / raw)
To: john; +Cc: robh+dt, matthias.bgg, netdev, sean.wang, devicetree,
linux-mediatek
In-Reply-To: <1485332455-34743-1-git-send-email-john@phrozen.org>
From: John Crispin <john@phrozen.org>
Date: Wed, 25 Jan 2017 09:20:54 +0100
> When the binding was defined, I was not aware that mt2701 was an earlier
> version of the SoC. For sake of consistency, the ethernet driver should
> use mt2701 inside the compat string as this is the earliest SoC with the
> ethernet core.
>
> The ethernet driver is currently of no real use until we finish and
> upstream the DSA driver. There are no users of this binding yet. It should
> be safe to fix this now before it is too late and we need to provide
> backward compatibility for the mt7623-eth compat string.
>
> Reported-by: Sean Wang <sean.wang@mediatek.com>
> Signed-off-by: John Crispin <john@phrozen.org>
Applied.
^ permalink raw reply
* Re: NAPI on USB network drivers
From: David Miller @ 2017-01-25 19:32 UTC (permalink / raw)
To: oneukum; +Cc: hayeswang, netdev, linux-usb
In-Reply-To: <1485336881.16604.2.camel@suse.com>
From: Oliver Neukum <oneukum@suse.com>
Date: Wed, 25 Jan 2017 10:34:41 +0100
> looking at r8152 I noticed that it uses NAPI. I never considered
> this for the generic USB networking code as you cannot disable
> interrupts for USB. Is it still worth it? What are the benefits?
I think it's not a good approach for getting GRO.
Exactly because of the issue you raise, in that USB drivers
cannot stop the URBs from coming in while running their poll
method.
^ permalink raw reply
* Re: [PATCH net v2 0/4] r8152: fix scheduling napi
From: David Miller @ 2017-01-25 19:31 UTC (permalink / raw)
To: hayeswang-Rasf1IRRPZFBDgjK7y7TUQ
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, nic_swsd-Rasf1IRRPZFBDgjK7y7TUQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1394712342-15778-242-Taiwan-albertk-Rasf1IRRPZFBDgjK7y7TUQ@public.gmane.org>
From: Hayes Wang <hayeswang-Rasf1IRRPZFBDgjK7y7TUQ@public.gmane.org>
Date: Wed, 25 Jan 2017 16:13:17 +0800
> v2:
> Add smp_mb__after_atomic() for patch #1.
>
> v1:
> Scheduling the napi during the following periods would let it be ignored.
> And the events wouldn't be handled until next napi_schedule() is called.
>
> 1. after napi_disable and before napi_enable().
> 2. after all actions of napi function is completed and before calling
> napi_complete().
>
> If no next napi_schedule() is called, tx or rx would stop working.
>
> In order to avoid these situations, the followings solutions are applied.
>
> 1. prevent start_xmit() from calling napi_schedule() during runtime suspend
> or after napi_disable().
> 2. re-schedule the napi for tx if it is necessary.
> 3. check if any rx is finished or not after napi_enable().
I think the fundamental issue is that since you can't stop URBs from
queueing up, you cannot properly synchronize NAPI and schedule polling
properly.
>From my perspective what happened here is you want GRO support, but it
comes at the expense of this extremely racey NAPI support which does
not at all achieve one of the main advantages of NAPI which is
interrupt mitigation.
It would have been so much better to implement a generic way for
drivers to get GRO support without NAPI, especially if their packet
feeding engine works the way that the USB networking drivers's do.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 net-next 1/2] net: dsa: mv88e6xxx: Workaround missing PHY ID on mv88e6390
From: Andrew Lunn @ 2017-01-25 19:30 UTC (permalink / raw)
To: Vivien Didelot; +Cc: Gregory CLEMENT, David Miller, netdev
In-Reply-To: <87r33r3tkw.fsf@weeman.i-did-not-set--mail-host-address--so-tickle-me>
On Wed, Jan 25, 2017 at 01:03:43PM -0500, Vivien Didelot wrote:
> 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)
This should be 0x3f0. There are 10 bits for the device model, of which
Marvell uses the lowest 4 for version.
> *val |= chip->info->prod_num << 4;
#define PORT_SWITCH_ID_PROD_NUM_6190 0x190
#define PORT_SWITCH_ID_PROD_NUM_6190X 0x0a0
#define PORT_SWITCH_ID_PROD_NUM_6191 0x191
#define PORT_SWITCH_ID_PROD_NUM_6290 0x290
#define PORT_SWITCH_ID_PROD_NUM_6390 0x390
#define PORT_SWITCH_ID_PROD_NUM_6390X 0x0a1
That still gives us 6 different PHY IDs, and the shift will cause is
to modify the OUI, so it is no longer a Marvell OUI.
Andrew
^ permalink raw reply
* Re: [PATCH net-next 3/3] net/tcp-fastopen: Add new API support
From: Wei Wang @ 2017-01-25 19:30 UTC (permalink / raw)
To: David Miller
Cc: Willy Tarreau, Eric Dumazet, Linux Kernel Network Developers,
Eric Dumazet, Yuchung Cheng, Wei Wang
In-Reply-To: <20170125.140333.788366320476056385.davem@davemloft.net>
> Note that I am not sure we correctly test that a second connect() can be
> done, and I am not sure kernel would check that the remote IP and
> destination port is the same.
> Ie what should happen for
> setsockopt(fd, SOL_TCP, TCP_FASTOPEN_CONNECT, &on, 4)
> connect(fd, "1.2.3.4:80")
> connect(fd, "55.66.77.88:4000")
I wrote a simple code to test this scenario and the second connect()
returns EISCONN as well even though the destination IP is different.
On Wed, Jan 25, 2017 at 11:03 AM, David Miller <davem@davemloft.net> wrote:
> From: Wei Wang <tracywwnj@gmail.com>
> Date: Wed, 25 Jan 2017 10:54:50 -0800
>
>>> Yes sorry David, for me it's OK. If Wei runs his whole series of tests
>>> on it again, it should be perfect.
>>
>> I just ran all the TFO related tests with Willy's patch on top of this
>> patch series.
>> And everything passes.
>
> Great, I'll apply everything, thanks.
^ permalink raw reply
* Re: [PATCH net-next] net/tcp-fastopen: make connect()'s return case more consistent with non-TFO
From: David Miller @ 2017-01-25 19:12 UTC (permalink / raw)
To: w; +Cc: netdev, weiwan, ycheng, edumazet
In-Reply-To: <1485351766-17124-1-git-send-email-w@1wt.eu>
From: Willy Tarreau <w@1wt.eu>
Date: Wed, 25 Jan 2017 14:42:46 +0100
> Without TFO, any subsequent connect() call after a successful one returns
> -1 EISCONN. The last API update ensured that __inet_stream_connect() can
> return -1 EINPROGRESS in response to sendmsg() when TFO is in use to
> indicate that the connection is now in progress. Unfortunately since this
> function is used both for connect() and sendmsg(), it has the undesired
> side effect of making connect() now return -1 EINPROGRESS as well after
> a successful call, while at the same time poll() returns POLLOUT. This
> can confuse some applications which happen to call connect() and to
> check for -1 EISCONN to ensure the connection is usable, and for which
> EINPROGRESS indicates a need to poll, causing a loop.
>
> This problem was encountered in haproxy where a call to connect() is
> precisely used in certain cases to confirm a connection's readiness.
> While arguably haproxy's behaviour should be improved here, it seems
> important to aim at a more robust behaviour when the goal of the new
> API is to make it easier to implement TFO in existing applications.
>
> This patch simply ensures that we preserve the same semantics as in
> the non-TFO case on the connect() syscall when using TFO, while still
> returning -1 EINPROGRESS on sendmsg(). For this we simply tell
> __inet_stream_connect() whether we're doing a regular connect() or in
> fact connecting for a sendmsg() call.
>
> Cc: Wei Wang <weiwan@google.com>
> Cc: Yuchung Cheng <ycheng@google.com>
> Cc: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Willy Tarreau <w@1wt.eu>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/3] net/tcp-fastopen: Add new userspace API support
From: David Miller @ 2017-01-25 19:09 UTC (permalink / raw)
To: tracywwnj; +Cc: netdev, edumazet, ycheng, weiwan
In-Reply-To: <20170123185922.48046-1-tracywwnj@gmail.com>
From: Wei Wang <tracywwnj@gmail.com>
Date: Mon, 23 Jan 2017 10:59:19 -0800
> The patch series is to add support for new userspace API for TCP fastopen
> sockets.
> In the current code, user has to call sendto()/sendmsg() with special flag
> MSG_FASTOPEN for TCP fastopen sockets. This API is quite different from the
> normal TCP socket API and can be cumbersome for applications to make use
> fastopen sockets.
> So this new patch introduces a new way of using TCP fastopen sockets which
> is similar to normal TCP sockets with a new sockopt TCP_FASTOPEN_CONNECT.
> More details about it is described in the third patch.
> (First 2 patches are preparations for the third patch.)
Series applied.
^ permalink raw reply
* Re: [PATCH net-next 3/3] net/tcp-fastopen: Add new API support
From: David Miller @ 2017-01-25 19:03 UTC (permalink / raw)
To: tracywwnj; +Cc: w, eric.dumazet, netdev, edumazet, ycheng, weiwan
In-Reply-To: <CAC15z3hG36VcanxLXtvxP-ta=Srom8P6E5Rds+jGjJ8vLj7TeQ@mail.gmail.com>
From: Wei Wang <tracywwnj@gmail.com>
Date: Wed, 25 Jan 2017 10:54:50 -0800
>> Yes sorry David, for me it's OK. If Wei runs his whole series of tests
>> on it again, it should be perfect.
>
> I just ran all the TFO related tests with Willy's patch on top of this
> patch series.
> And everything passes.
Great, I'll apply everything, thanks.
^ permalink raw reply
* Re: [PATCH net-next] tcp: reduce skb overhead in selected places
From: David Miller @ 2017-01-25 19:03 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1485369532.5145.50.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 25 Jan 2017 10:38:52 -0800
> Do you think we could change __pskb_pull_tail() right away and fix the
> few places that would break, or should we add various helpers with extra
> parameters to take a safe route ?
It should always be safe as long as we see no socket attached on RX,
right?
That's the only real case where truesize adjustments can cause trouble.
^ permalink raw reply
* Re: [PATCH net-next 3/3] net/tcp-fastopen: Add new API support
From: Eric Dumazet @ 2017-01-25 19:03 UTC (permalink / raw)
To: Wei Wang
Cc: Willy Tarreau, David Miller, Linux Kernel Network Developers,
Eric Dumazet, Yuchung Cheng, Wei Wang
In-Reply-To: <CAC15z3hG36VcanxLXtvxP-ta=Srom8P6E5Rds+jGjJ8vLj7TeQ@mail.gmail.com>
On Wed, 2017-01-25 at 10:54 -0800, Wei Wang wrote:
> > Yes sorry David, for me it's OK. If Wei runs his whole series of tests
> > on it again, it should be perfect.
>
> I just ran all the TFO related tests with Willy's patch on top of this
> patch series.
> And everything passes.
Note that I am not sure we correctly test that a second connect() can be
done, and I am not sure kernel would check that the remote IP and
destination port is the same.
Ie what should happen for
setsockopt(fd, SOL_TCP, TCP_FASTOPEN_CONNECT, &on, 4)
connect(fd, "1.2.3.4:80")
connect(fd, "55.66.77.88:4000")
This multiple connect() thing should have been forbidden in the first
place really.
^ permalink raw reply
* RE: [PATCH net-next v6 2/4] net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341
From: Jon Pannell @ 2017-01-25 18:58 UTC (permalink / raw)
To: Gregory CLEMENT, Andrew Lunn, Bob Bernstein
Cc: Vivien Didelot, Florian Fainelli, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org, David S. Miller, Jason Cooper,
Sebastian Hesselbarth, Thomas Petazzoni,
linux-arm-kernel@lists.infradead.org, Nadav Haklai, Wilson Ding,
Kostya Porotchkin, Joe Zhou
In-Reply-To: <8760l3375t.fsf@free-electrons.com>
Adding Bob Bernstein
Jon Pannell
-----Original Message-----
From: Gregory CLEMENT [mailto:gregory.clement@free-electrons.com]
Sent: Tuesday, January 24, 2017 11:56 PM
To: Andrew Lunn <andrew@lunn.ch>
Cc: Vivien Didelot <vivien.didelot@savoirfairelinux.com>; Florian Fainelli <f.fainelli@gmail.com>; netdev@vger.kernel.org; linux-kernel@vger.kernel.org; David S. Miller <davem@davemloft.net>; Jason Cooper <jason@lakedaemon.net>; Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>; Thomas Petazzoni <thomas.petazzoni@free-electrons.com>; linux-arm-kernel@lists.infradead.org; Nadav Haklai <nadavh@marvell.com>; Wilson Ding <dingwei@marvell.com>; Kostya Porotchkin <kostap@marvell.com>; Joe Zhou <shjzhou@marvell.com>; Jon Pannell <jpannell@marvell.com>
Subject: Re: [PATCH net-next v6 2/4] net: dsa: mv88e6xxx: Add support for ethernet switch 88E6341
Hi Andrew,
On mer., janv. 25 2017, Andrew Lunn <andrew@lunn.ch> wrote:
>> + [MV88E6341] = {
>> + .prod_num = PORT_SWITCH_ID_PROD_NUM_6341,
>> + .family = MV88E6XXX_FAMILY_6341,
>> + .name = "Marvell 88E6341",
>> + .num_databases = 4096,
>> + .num_ports = 6,
>> + .port_base_addr = 0x10,
>> + .global1_addr = 0x1b,
>> + .age_time_coeff = 15000,
>
> Hi Gregory
>
> Please could you check this timer in the datasheet. There is currently
> a bug in the mv88e6390 support code. I also set it to 15s. But in fact
> it is 3.75 seconds. The 6341 might also use 3.75 seconds.
When I read your series I also thought about it and indeed it is 3.75 seconds. I will fix it.
Thanks,
Gregory
>
> Thanks
> Andrew
^ permalink raw reply
* Re: [PATCH net-next 3/3] net/tcp-fastopen: Add new API support
From: Wei Wang @ 2017-01-25 18:54 UTC (permalink / raw)
To: Willy Tarreau
Cc: David Miller, Eric Dumazet, Linux Kernel Network Developers,
Eric Dumazet, Yuchung Cheng, Wei Wang
In-Reply-To: <20170125175458.GF23545@1wt.eu>
> Yes sorry David, for me it's OK. If Wei runs his whole series of tests
> on it again, it should be perfect.
I just ran all the TFO related tests with Willy's patch on top of this
patch series.
And everything passes.
On Wed, Jan 25, 2017 at 9:54 AM, Willy Tarreau <w@1wt.eu> wrote:
> 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: stmmac: GMAC_RGSMIIIS reports bogus values
From: Vineet Gupta @ 2017-01-25 18:47 UTC (permalink / raw)
To: Alexey Brodkin, peppe.cavallaro@st.com
Cc: manabian@gmail.com, linux-kernel@vger.kernel.org,
fabrice.gasnier@st.com, linux-snps-arc@lists.infradead.org,
alexandre.torgue@gmail.com, preid@electromag.com.au,
netdev@vger.kernel.org, davem@davemloft.net
In-Reply-To: <1485369563.7117.81.camel@synopsys.com>
On 01/25/2017 10:39 AM, Alexey Brodkin wrote:
>> Also I wonder if, other version of the stmmac worked on this platform
>> before.
> It did work and still works. The only problem is we're getting
> a lot of noise now about bogus link status change. That's because
> this info is now in pr_info() compared to being previously in pr_debug().
While we sort out the real technical details, it is OK to go back to pr_debug
please - print_once or some such !
There is lot of useless console noise when we run any networking loads here !
echo 0 > /proc/sys/kernel/printk
only helps in that it is not printed on console but clobbers dmesg nonetheless !
Thx,
-Vineet
^ permalink raw reply
* Re: stmmac: GMAC_RGSMIIIS reports bogus values
From: Alexey Brodkin @ 2017-01-25 18:39 UTC (permalink / raw)
To: peppe.cavallaro@st.com
Cc: manabian@gmail.com, linux-kernel@vger.kernel.org,
fabrice.gasnier@st.com, linux-snps-arc@lists.infradead.org,
alexandre.torgue@gmail.com, preid@electromag.com.au,
netdev@vger.kernel.org, Vineet Gupta, davem@davemloft.net
In-Reply-To: <a1f114cc-6120-154c-a3f7-3e0389d38e36@st.com>
Hi Giuseppe,
On Mon, 2016-11-14 at 09:14 +0100, Giuseppe CAVALLARO wrote:
> Hello Alexey
>
> Sorry for my late reply. In that case, I think that the stmmac
> is using own RGMII/SGMII support (PCS) to dialog with the
> transceiver. I think, from the HW capability register
> this feature is present and the driver is using it as default.
Yep looks like that.
> I kindly ask you to verify if this is your setup or if you
> do not want to use it. In that case, it is likely we need to
> add some code in the driver.
Well GMAC's databook says:
--------------------------->8--------------------------
The DWC_gmac provides an IEEE 802.3z compliant 10-bit
Physical Coding Sublayer (PCS) interface that you can use
when the MAC is configured for the TBI, RTBI, or SGMII PHY
interface.
...
You can include the optional PCS module in the DWC_gmac by
selecting the TBI, RTBI, or SGMII interface in coreConsultant
during configuration.
--------------------------->8--------------------------
But we use RGMII for communication with the PHY.
And from the quote above I would conclude that for RGMII we should
have PCS excluded from GMAC.
I just sent email to GMAC developers here in Synopsys and
hopefully will get some clarifications from them soon.
Probably correct solution is as simple as:
--------------------------->8--------------------------
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
index a276a32d57f2..f4b67dc7d530 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
+++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c
@@ -803,13 +803,7 @@ static void stmmac_check_pcs_mode(struct stmmac_priv *priv)
int interface = priv->plat->interface;
if (priv->dma_cap.pcs) {
- if ((interface == PHY_INTERFACE_MODE_RGMII) ||
- (interface == PHY_INTERFACE_MODE_RGMII_ID) ||
- (interface == PHY_INTERFACE_MODE_RGMII_RXID) ||
- (interface == PHY_INTERFACE_MODE_RGMII_TXID)) {
- netdev_dbg(priv->dev, "PCS RGMII support enabled\n");
- priv->hw->pcs = STMMAC_PCS_RGMII;
- } else if (interface == PHY_INTERFACE_MODE_SGMII) {
+ if (interface == PHY_INTERFACE_MODE_SGMII) {
netdev_dbg(priv->dev, "PCS SGMII support enabled\n");
priv->hw->pcs = STMMAC_PCS_SGMII;
}
--------------------------->8--------------------------
> Also I wonder if, other version of the stmmac worked on this platform
> before.
It did work and still works. The only problem is we're getting
a lot of noise now about bogus link status change. That's because
this info is now in pr_info() compared to being previously in pr_debug().
-Alexey
^ permalink raw reply related
* Re: [PATCH net-next] tcp: reduce skb overhead in selected places
From: Eric Dumazet @ 2017-01-25 18:38 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20170125.131717.489451306351372553.davem@davemloft.net>
On Wed, 2017-01-25 at 13:17 -0500, David Miller wrote:
> Applied, thanks Eric.
Thanks David.
It looks IPv6 potential big network headers are also a threat :
Various pskb_may_pull() to pull headers might reallocate skb->head,
but skb->truesize is not updated in __pskb_pull_tail()
We probably need to update skb->truesize, but it is tricky as the prior
skb->truesize value might have been used for memory accounting when skb
was stored in some queue.
Do you think we could change __pskb_pull_tail() right away and fix the
few places that would break, or should we add various helpers with extra
parameters to take a safe route ?
^ permalink raw reply
* [PATCH v6 3/3] Bluetooth: btusb: Configure Marvell to use one of the pins for oob wakeup
From: Rajat Jain @ 2017-01-25 18:35 UTC (permalink / raw)
To: Rob Herring, Mark Rutland, Marcel Holtmann, Gustavo Padovan,
Johan Hedberg, Amitkumar Karwar, Wei-Ning Huang, Xinming Hu,
netdev, devicetree, linux-bluetooth, Brian Norris, linux-kernel
Cc: Rajat Jain, rajatxjain
In-Reply-To: <20170125183500.8292-1-rajatja@google.com>
The Marvell devices may have many gpio pins, and hence for wakeup
on these out-of-band pins, the chip needs to be told which pin is
to be used for wakeup, using an hci command.
Thus, we read the pin number etc from the device tree node and send
a command to the chip.
Signed-off-by: Rajat Jain <rajatja@google.com>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Acked-by: Rob Herring <robh@kernel.org>
---
v6: same as v5
v5: same as v5
v4: same as v3
v3: * remove the Marvell specific id table and check
* Add reference to marvell-bt-8xxx.txt in btusb.txt
* Add "Reviewed-by" and "Acked-by"
v2: Fix the binding document to specify to use "wakeup" interrupt-name
Documentation/devicetree/bindings/net/btusb.txt | 3 ++
.../{marvell-bt-sd8xxx.txt => marvell-bt-8xxx.txt} | 46 +++++++++++++++----
drivers/bluetooth/btusb.c | 51 ++++++++++++++++++++++
3 files changed, 92 insertions(+), 8 deletions(-)
rename Documentation/devicetree/bindings/net/{marvell-bt-sd8xxx.txt => marvell-bt-8xxx.txt} (50%)
diff --git a/Documentation/devicetree/bindings/net/btusb.txt b/Documentation/devicetree/bindings/net/btusb.txt
index 2c0355c85972..01fa2d4188d4 100644
--- a/Documentation/devicetree/bindings/net/btusb.txt
+++ b/Documentation/devicetree/bindings/net/btusb.txt
@@ -10,6 +10,9 @@ Required properties:
"usb1286,204e" (Marvell 8997)
+Also, vendors that use btusb may have device additional properties, e.g:
+Documentation/devicetree/bindings/net/marvell-bt-8xxx.txt
+
Optional properties:
- interrupt-parent: phandle of the parent interrupt controller
diff --git a/Documentation/devicetree/bindings/net/marvell-bt-sd8xxx.txt b/Documentation/devicetree/bindings/net/marvell-bt-8xxx.txt
similarity index 50%
rename from Documentation/devicetree/bindings/net/marvell-bt-sd8xxx.txt
rename to Documentation/devicetree/bindings/net/marvell-bt-8xxx.txt
index 6a9a63cb0543..9be1059ff03f 100644
--- a/Documentation/devicetree/bindings/net/marvell-bt-sd8xxx.txt
+++ b/Documentation/devicetree/bindings/net/marvell-bt-8xxx.txt
@@ -1,16 +1,21 @@
-Marvell 8897/8997 (sd8897/sd8997) bluetooth SDIO devices
+Marvell 8897/8997 (sd8897/sd8997) bluetooth devices (SDIO or USB based)
------
+The 8997 devices supports multiple interfaces. When used on SDIO interfaces,
+the btmrvl driver is used and when used on USB interface, the btusb driver is
+used.
Required properties:
- compatible : should be one of the following:
- * "marvell,sd8897-bt"
- * "marvell,sd8997-bt"
+ * "marvell,sd8897-bt" (for SDIO)
+ * "marvell,sd8997-bt" (for SDIO)
+ * "usb1286,204e" (for USB)
Optional properties:
- marvell,cal-data: Calibration data downloaded to the device during
initialization. This is an array of 28 values(u8).
+ This is only applicable to SDIO devices.
- marvell,wakeup-pin: It represents wakeup pin number of the bluetooth chip.
firmware will use the pin to wakeup host system (u16).
@@ -18,10 +23,15 @@ Optional properties:
platform. The value will be configured to firmware. This
is needed to work chip's sleep feature as expected (u16).
- interrupt-parent: phandle of the parent interrupt controller
- - interrupts : interrupt pin number to the cpu. Driver will request an irq based
- on this interrupt number. During system suspend, the irq will be
- enabled so that the bluetooth chip can wakeup host platform under
- certain condition. During system resume, the irq will be disabled
+ - interrupt-names: Used only for USB based devices (See below)
+ - interrupts : specifies the interrupt pin number to the cpu. For SDIO, the
+ driver will use the first interrupt specified in the interrupt
+ array. For USB based devices, the driver will use the interrupt
+ named "wakeup" from the interrupt-names and interrupt arrays.
+ The driver will request an irq based on this interrupt number.
+ During system suspend, the irq will be enabled so that the
+ bluetooth chip can wakeup host platform under certain
+ conditions. During system resume, the irq will be disabled
to make sure unnecessary interrupt is not received.
Example:
@@ -29,7 +39,9 @@ Example:
IRQ pin 119 is used as system wakeup source interrupt.
wakeup pin 13 and gap 100ms are configured so that firmware can wakeup host
using this device side pin and wakeup latency.
-calibration data is also available in below example.
+
+Example for SDIO device follows (calibration data is also available in
+below example).
&mmc3 {
status = "okay";
@@ -54,3 +66,21 @@ calibration data is also available in below example.
marvell,wakeup-gap-ms = /bits/ 16 <0x64>;
};
};
+
+Example for USB device:
+
+&usb_host1_ohci {
+ status = "okay";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mvl_bt1: bt@1 {
+ compatible = "usb1286,204e";
+ reg = <1>;
+ interrupt-parent = <&gpio0>;
+ interrupt-names = "wakeup";
+ interrupts = <119 IRQ_TYPE_LEVEL_LOW>;
+ marvell,wakeup-pin = /bits/ 16 <0x0d>;
+ marvell,wakeup-gap-ms = /bits/ 16 <0x64>;
+ };
+};
diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
index 0e7aed20b71b..c61ff4b3ec84 100644
--- a/drivers/bluetooth/btusb.c
+++ b/drivers/bluetooth/btusb.c
@@ -2343,6 +2343,50 @@ static int btusb_shutdown_intel(struct hci_dev *hdev)
return 0;
}
+#ifdef CONFIG_PM
+/* Configure an out-of-band gpio as wake-up pin, if specified in device tree */
+static int marvell_config_oob_wake(struct hci_dev *hdev)
+{
+ struct sk_buff *skb;
+ struct btusb_data *data = hci_get_drvdata(hdev);
+ struct device *dev = &data->udev->dev;
+ u16 pin, gap, opcode;
+ int ret;
+ u8 cmd[5];
+
+ /* Move on if no wakeup pin specified */
+ if (of_property_read_u16(dev->of_node, "marvell,wakeup-pin", &pin) ||
+ of_property_read_u16(dev->of_node, "marvell,wakeup-gap-ms", &gap))
+ return 0;
+
+ /* Vendor specific command to configure a GPIO as wake-up pin */
+ opcode = hci_opcode_pack(0x3F, 0x59);
+ cmd[0] = opcode & 0xFF;
+ cmd[1] = opcode >> 8;
+ cmd[2] = 2; /* length of parameters that follow */
+ cmd[3] = pin;
+ cmd[4] = gap; /* time in ms, for which wakeup pin should be asserted */
+
+ skb = bt_skb_alloc(sizeof(cmd), GFP_KERNEL);
+ if (!skb) {
+ bt_dev_err(hdev, "%s: No memory\n", __func__);
+ return -ENOMEM;
+ }
+
+ memcpy(skb_put(skb, sizeof(cmd)), cmd, sizeof(cmd));
+ hci_skb_pkt_type(skb) = HCI_COMMAND_PKT;
+
+ ret = btusb_send_frame(hdev, skb);
+ if (ret) {
+ bt_dev_err(hdev, "%s: configuration failed\n", __func__);
+ kfree_skb(skb);
+ return ret;
+ }
+
+ return 0;
+}
+#endif
+
static int btusb_set_bdaddr_marvell(struct hci_dev *hdev,
const bdaddr_t *bdaddr)
{
@@ -2918,6 +2962,13 @@ static int btusb_probe(struct usb_interface *intf,
err = btusb_config_oob_wake(hdev);
if (err)
goto out_free_dev;
+
+ /* Marvell devices may need a specific chip configuration */
+ if (id->driver_info & BTUSB_MARVELL && data->oob_wake_irq) {
+ err = marvell_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);
--
2.11.0.483.g087da7b7c-goog
^ permalink raw reply related
* [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
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