* Re: TCP out of memory - possible bug [3.18.0-rc3] / sched?
From: Markus Trippelsdorf @ 2015-01-04 21:39 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Tomasz Mloduchowski, netdev
In-Reply-To: <1420405287.32621.8.camel@edumazet-glaptop2.roam.corp.google.com>
On 2015.01.04 at 13:01 -0800, Eric Dumazet wrote:
> On Sun, 2015-01-04 at 09:42 +0100, Markus Trippelsdorf wrote:
>
> > Any news on this issue?
> >
> > I stumbled across the same problem today with 3.19.0-rc2:
>
> What make you think it was fixed in 3.19.0-rc2 ?
Nothing.
> Have you tried a bisection ?
It was a one time event for me. So a bisection is out of the question.
But Tomasz wrote that he can reproduce the issue reliably.
Have you tried a bisection, Tomasz?
--
Markus
^ permalink raw reply
* Re: [PATCH net-next v1 0/7] net: extend ethtool link mode bitmaps to 48 bits
From: Ben Hutchings @ 2015-01-04 21:55 UTC (permalink / raw)
To: David Decotigny
Cc: Amir Vadai, Florian Fainelli, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, David Decotigny,
David S. Miller, Jason Wang, Michael S. Tsirkin, Herbert Xu,
Al Viro, Masatake YAMATO, Xi Wang, Neil Horman, WANG Cong,
Flavio Leitner, Tom Gundersen, Jiri Pirko, Vlad Yasevich,
Eric W. Biederman, Saeed Mahameed, Venkata Duvvuru,
Govindarajulu Varadarajan
In-Reply-To: <1420405017-23278-1-git-send-email-ddecotig-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 507 bytes --]
On Sun, 2015-01-04 at 12:56 -0800, David Decotigny wrote:
[...]
> I can send updates to other drivers, even though it's rather pointless
> to update 1G drivers at this point for example. Please let me know,
> but I'd prefer to do this in follow-up patches outside this first
> patch series.
[...]
They should be changed to ensure they reject setting any of the high
advertising flags, but it's not urgent.
Ben.
--
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v1 1/7] net: ethtool: extend link mode support to 48 bits
From: Ben Hutchings @ 2015-01-04 22:01 UTC (permalink / raw)
To: David Decotigny
Cc: Amir Vadai, Florian Fainelli, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, David Decotigny,
David S. Miller, Jason Wang, Michael S. Tsirkin, Herbert Xu,
Al Viro, Masatake YAMATO, Xi Wang, Neil Horman, WANG Cong,
Flavio Leitner, Tom Gundersen, Jiri Pirko, Vlad Yasevich,
Eric W. Biederman, Saeed Mahameed, Venkata Duvvuru,
Govindarajulu Varadarajan
In-Reply-To: <1420405017-23278-2-git-send-email-ddecotig-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 3096 bytes --]
On Sun, 2015-01-04 at 12:56 -0800, David Decotigny wrote:
> From: David Decotigny <decot-Ypc/8FJVVoBWk0Htik3J/w@public.gmane.org>
This is mostly fine, with just a few minor issues.
> Signed-off-by: David Decotigny <decot-Ypc/8FJVVoBWk0Htik3J/w@public.gmane.org>
> ---
> include/uapi/linux/ethtool.h | 130 ++++++++++++++++++++++++++++++++++++-------
> 1 file changed, 110 insertions(+), 20 deletions(-)
>
> diff --git a/include/uapi/linux/ethtool.h b/include/uapi/linux/ethtool.h
> index 5f66d9c..61e7734 100644
> --- a/include/uapi/linux/ethtool.h
> +++ b/include/uapi/linux/ethtool.h
[...]
> @@ -123,6 +140,46 @@ static inline __u32 ethtool_cmd_speed(const struct ethtool_cmd *ep)
> return (ep->speed_hi << 16) | ep->speed;
> }
>
> +/**
> + * MAKE_ETHTOOL_LINK_MODE_ACCESSORS - create the link_mode accessors
> + * Macro to generate the %ethtool_cmd_supported_*,
> + * %ethtool_cmd_advertising_*, %ethtool_cmd_lp_advertising_*,
> + * %ethtool_eee_supported_*, %ethtool_eee_advertised_*,
> + * %ethtool_eee_lp_advertised_* families of functions.
> + *
> + * Macro args:
Delete the 'Macro args:' heading; that's implied by the @ prefixes.
> + * @struct_name: either %ethtool_cmd or %ethtool_eee
> + * @field_name: name of the fields in %struct_name to
> + * access. supported/advertising/lp_advertising for ethtool_cmd,
> + * supported/advertised/lp_advertised for ethtool_eee
> + *
> + * Generates the following static functions:
> + * @ethtool_cmd_supported(const struct ethtool_cmd*): returns
> + * the 64b value of %supported fields (the upper bits 63..48 are 0)
> + * @ethtool_cmd_supported_set(struct ethtool_cmd*,
> + * ethtool_link_mode_mask_t value): set the %supported fields to
> + * given %value (only the lower 48 bits used, upper bits 63..48
> + * ignored)
Delete the @ prefixes from these headings.
> + * Same doc for all the other functions.
> + */
> +#define MAKE_ETHTOOL_LINK_MODE_ACCESSORS(struct_name, field_name) \
I think the name should begin with ETHTOOL but it's not a big deal.
[...]
> @@ -1192,6 +1273,9 @@ enum ethtool_sfeatures_retval_bits {
> #define SPARC_ETH_GSET ETHTOOL_GSET
> #define SPARC_ETH_SSET ETHTOOL_SSET
>
> +/* Do not use the following macros directly to update
> + * ethtool_cmd::supported, ethtool_eee::supported. Please use
> + * ethtool_(cmd|eee)_supported(|_set) instead */
The ending */ belongs on a new line.
> #define SUPPORTED_10baseT_Half (1 << 0)
> #define SUPPORTED_10baseT_Full (1 << 1)
> #define SUPPORTED_100baseT_Half (1 << 2)
> @@ -1223,7 +1307,12 @@ enum ethtool_sfeatures_retval_bits {
> #define SUPPORTED_56000baseCR4_Full (1 << 28)
> #define SUPPORTED_56000baseSR4_Full (1 << 29)
> #define SUPPORTED_56000baseLR4_Full (1 << 30)
> +/* TODO: for bit indices >= 31, make sure to shift 1ULL instead of 1 */
[...]
I don't think that comment is necessary; the compiler will surely warn
if someone forgets.
Ben.
--
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v1 2/7] net: phy: extend link mode support to 48 bits
From: Ben Hutchings @ 2015-01-04 22:03 UTC (permalink / raw)
To: David Decotigny
Cc: Amir Vadai, Florian Fainelli, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-api-u79uwXL29TY76Z2rM5mHXA, David Decotigny,
David S. Miller, Jason Wang, Michael S. Tsirkin, Herbert Xu,
Al Viro, Masatake YAMATO, Xi Wang, Neil Horman, WANG Cong,
Flavio Leitner, Tom Gundersen, Jiri Pirko, Vlad Yasevich,
Eric W. Biederman, Saeed Mahameed, Venkata Duvvuru,
Govindarajulu Varadarajan
In-Reply-To: <1420405017-23278-3-git-send-email-ddecotig-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 2212 bytes --]
On Sun, 2015-01-04 at 12:56 -0800, David Decotigny wrote:
> From: David Decotigny <decot-Ypc/8FJVVoBWk0Htik3J/w@public.gmane.org>
>
> Signed-off-by: David Decotigny <decot-Ypc/8FJVVoBWk0Htik3J/w@public.gmane.org>
> ---
> drivers/net/phy/phy.c | 29 ++++++++++++++---------------
> drivers/net/phy/phy_device.c | 4 ++--
> include/linux/phy.h | 10 +++++-----
> 3 files changed, 21 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
> index 767cd11..e9c8499 100644
> --- a/drivers/net/phy/phy.c
> +++ b/drivers/net/phy/phy.c
[...]
> @@ -245,7 +246,7 @@ static inline unsigned int phy_find_valid(unsigned int idx, u32 features)
> */
> static void phy_sanitize_settings(struct phy_device *phydev)
> {
> - u32 features = phydev->supported;
> + ethtool_link_mode_mask_t features = phydev->supported;
> unsigned int idx;
>
> /* Sanitize settings based on PHY capabilities */
> @@ -279,13 +280,13 @@ int phy_ethtool_sset(struct phy_device *phydev, struct ethtool_cmd *cmd)
> return -EINVAL;
>
> /* We make sure that we don't pass unsupported values in to the PHY */
> - cmd->advertising &= phydev->supported;
> + phydev->advertising = ethtool_cmd_advertising(cmd) & phydev->supported;
phydev->advertising should not be changed until after the following
validation. Use a local variable for this.
> /* Verify the settings we care about. */
> if (cmd->autoneg != AUTONEG_ENABLE && cmd->autoneg != AUTONEG_DISABLE)
> return -EINVAL;
>
> - if (cmd->autoneg == AUTONEG_ENABLE && cmd->advertising == 0)
> + if (cmd->autoneg == AUTONEG_ENABLE && phydev->advertising == 0)
> return -EINVAL;
>
> if (cmd->autoneg == AUTONEG_DISABLE &&
> @@ -300,8 +301,6 @@ int phy_ethtool_sset(struct phy_device *phydev, struct ethtool_cmd *cmd)
>
> phydev->speed = speed;
>
> - phydev->advertising = cmd->advertising;
> -
> if (AUTONEG_ENABLE == cmd->autoneg)
> phydev->advertising |= ADVERTISED_Autoneg;
> else
[...]
The assignment to phydev->advertising should probably remain here.
Ben.
--
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] Align member-assigns in a structure-copy block
From: Giel van Schijndel @ 2015-01-04 23:02 UTC (permalink / raw)
To: linux-kernel
Cc: Kalle Valo, Eliad Peller, John W. Linville, Arik Nemtsov,
open list:TI WILINK WIRELES..., open list:NETWORKING DRIVERS
In-Reply-To: <1420394427-19509-1-git-send-email-me@mortis.eu>
[-- Attachment #1: Type: text/plain, Size: 377 bytes --]
On Sun, Jan 04, 2015 at 19:00:22 +0100, Giel van Schijndel wrote:
> This highlights the differences (errors).
> ---
Forgot to:
Signed-off-by: Giel van Schijndel <me@mortis.eu>
--
Met vriendelijke groet,
With kind regards,
Giel van Schijndel
--
"Walking on water and developing software from a specification are easy
if both are frozen."
-- Edward V Berard
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix an infinite retry-loop
From: Giel van Schijndel @ 2015-01-04 23:04 UTC (permalink / raw)
To: linux-kernel
Cc: Jitendra Kalsaria, Ron Mercer, supporter:QLOGIC QLA3XXX NE...,
open list:QLOGIC QLA3XXX NE...
In-Reply-To: <1420394696-20099-1-git-send-email-me@mortis.eu>
[-- Attachment #1: Type: text/plain, Size: 741 bytes --]
On Sun, Jan 04, 2015 at 19:04:55 +0100, Giel van Schijndel wrote:
> This was clearly intended as a retry-10-times loop, but due to the
> absence of code incrementing the loop-counter it was practically a
> retry-forever loop.
>
> Rewritten it as a for-loop as well to make the loop-counter increment
> (as well as its potential absence) easier to spot.
> ---
Forgot to:
Signed-off-by: Giel van Schijndel <me@mortis.eu>
--
Met vriendelijke groet,
With kind regards,
Giel van Schijndel
--
"A computer is a stupid machine with the ability to do incredibly smart
things, while computer programmers are smart people with the ability to
do incredibly stupid things. They are, in short, a perfect match.
-- Bill Bryson
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH] Fix NUL (\0 or \x00) specification in string
From: Giel van Schijndel @ 2015-01-04 23:04 UTC (permalink / raw)
To: linux-kernel; +Cc: Armin Schindler, Karsten Keil, open list:ISDN SUBSYSTEM
In-Reply-To: <1420394722-20197-1-git-send-email-me@mortis.eu>
[-- Attachment #1: Type: text/plain, Size: 522 bytes --]
On Sun, Jan 04, 2015 at 19:05:22 +0100, Giel van Schijndel wrote:
> In C one can either use '\0' or '\x00' (or '\000') to add a NUL byte to
> a string. '\0x00' isn't part of these and will in fact result in a
> single NUL followed by "x00". This fixes that.
> ---
Forgot to:
Signed-off-by: Giel van Schijndel <me@mortis.eu>
--
Met vriendelijke groet,
With kind regards,
Giel van Schijndel
--
"There are 2 types of people in this world - those who like Chuck
Norris and those who are dead."
-- Jus12
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] Fix copy-paste bug: assign from src struct not dest
From: Giel van Schijndel @ 2015-01-04 23:02 UTC (permalink / raw)
To: linux-kernel
In-Reply-To: <1420394427-19509-2-git-send-email-me@mortis.eu>
[-- Attachment #1: Type: text/plain, Size: 210 bytes --]
On Sun, Jan 04, 2015 at 19:00:23 +0100, Giel van Schijndel wrote:
> ---
Forgot to:
Signed-off-by: Giel van Schijndel <me@mortis.eu>
--
Met vriendelijke groet,
With kind regards,
Giel van Schijndel
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH net-next v1 0/7] net: extend ethtool link mode bitmaps to 48 bits
From: Maciej Żenczykowski @ 2015-01-05 0:34 UTC (permalink / raw)
To: Ben Hutchings
Cc: David Decotigny, Amir Vadai, Florian Fainelli, Linux NetDev,
Linux Kernel Mailing List, linux-api-u79uwXL29TY76Z2rM5mHXA,
David Decotigny, David S. Miller, Jason Wang, Michael S. Tsirkin,
Herbert Xu, Al Viro, Masatake YAMATO, Xi Wang, Neil Horman,
WANG Cong, Flavio Leitner, Tom Gundersen, Jiri Pirko,
Vlad Yasevich, Eric W. Biederman, Saeed Mahameed, Venkata Duvvuru,
Govindaraj
In-Reply-To: <1420408540.5686.140.camel-/+tVBieCtBitmTQ+vhA3Yw@public.gmane.org>
>> I can send updates to other drivers, even though it's rather pointless
>> to update 1G drivers at this point for example. Please let me know,
>> but I'd prefer to do this in follow-up patches outside this first
>> patch series.
> [...]
>
> They should be changed to ensure they reject setting any of the high
> advertising flags, but it's not urgent.
if old drivers advertised a get/set_bits function while new drivers
advertised a get/set_new_bits function,
you could not updated any old drivers, and simply take care of
rejecting invalid bits in core, by calling set_new_bits if provided,
if not, rejecting bad bits and calling set_bits if no bad bits were
set.
^ permalink raw reply
* Re: [PATCH] net: wireless: rtlwifi: btcoexist: halbtc8821a2ant: Remove some unused functions
From: Larry Finger @ 2015-01-05 1:45 UTC (permalink / raw)
To: Rickard Strandqvist
Cc: Chaoming Li, Kalle Valo, Greg Kroah-Hartman, Fengguang Wu,
linux-wireless@vger.kernel.org, Network Development,
Linux Kernel Mailing List
In-Reply-To: <CAKXHbyOYO29uKA127qyYrCfpgQ2zoqBS9rAJME513oZ8JVdOug@mail.gmail.com>
On 01/03/2015 06:03 AM, Rickard Strandqvist wrote:
> 2015-01-03 7:05 GMT+01:00 Larry Finger <Larry.Finger@lwfinger.net>:
>
>> On 01/02/2015 02:26 PM, Rickard Strandqvist wrote:
>>
>>> Removes some functions that are not used anywhere:
>>> ex_halbtc8821a2ant_periodical() ex_halbtc8821a2ant_halt_notify()
>>> ex_halbtc8821a2ant_bt_info_notify()
>>> ex_halbtc8821a2ant_special_packet_notify()
>>> ex_halbtc8821a2ant_connect_notify() ex_halbtc8821a2ant_scan_notify()
>>> ex_halbtc8821a2ant_lps_notify() ex_halbtc8821a2ant_ips_notify()
>>> ex_halbtc8821a2ant_display_coex_info() ex_halbtc8821a2ant_init_coex_dm()
>>> ex_halbtc8821a2ant_init_hwconfig()
>>>
>>> This was partially found by using a static code analysis program called
>>> cppcheck.
>>>
>>> Signed-off-by: Rickard Strandqvist <rickard_strandqvist@
>>> spectrumdigital.se>
>>>
>>
>> I know that you have been told that including "net: wireless:" in the
>> subject line is discouraged. Please do not do this again. The staging
>> directory is different as GregKH uses "staging:" in the subject to route
>> patches, but wireless does not.
>>
>> As to the patch, NACK for the simple reason that I am currently working on
>> a number of changes to btcoexist. Some of these routines may end up being
>> removed, but others will not. Having your patch remove them, and one of
>> mine adding them back just constitutes a lot of churning of the source. In
>> addition, it greatly increases the probability of the source trees becoming
>> unsynchronized and getting merge conflicts.
>>
>> Larry
>>
>>
>
> Hi Larry
>
> I do not recognize that there has been no diskution on the subject of "net:
> wireless:"
> I use some sed call for this, so it's easy to fix. You want the "net:
> wireless:" part completely erased then?
> I check in Documentation/ but find any clear info for this.
>
> Sorry for the patch, is there any way for me to see that this is something
> that is being worked on?
These patches are the result of private communications between the Realtek
engineers and me. The only publication is in the "rock" branch of the git repo
at http://github.com/lwfinger/rtlwifi_new.git.
I do not understand the "use of some 'sed' call". If you edit the source and add
it to the git repo with the add and commit operations, then format-patch gives
you exactly what you need, and send-email does that operation.
Larry
^ permalink raw reply
* Re: [PATCH] net: flow: Guard against accessing non-existent attributes
From: Simon Horman @ 2015-01-05 2:04 UTC (permalink / raw)
To: John Fastabend; +Cc: John Fastabend, netdev
In-Reply-To: <54A1951A.2070209@gmail.com>
On Mon, Dec 29, 2014 at 09:53:30AM -0800, John Fastabend wrote:
> On 12/28/2014 06:17 PM, Simon Horman wrote:
> >Signed-off-by: Simon Horman <simon.horman@netronome.com>
> >---
> > net/core/flow_table.c | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
>
> Great thanks. I rolled it into the patches I should hopefully have
> ready to submit later today.
>
> By the way I got this working on rocker now so we can test it easier,
> I'll post the driver updates as well.
Great, excellent news.
^ permalink raw reply
* Re: [PATCH] net: flow: Allow actions and matches to be NULL in net_flow_put_flow()
From: Simon Horman @ 2015-01-05 2:06 UTC (permalink / raw)
To: John Fastabend; +Cc: John Fastabend, netdev
In-Reply-To: <54A195C7.3010009@gmail.com>
On Mon, Dec 29, 2014 at 09:56:23AM -0800, John Fastabend wrote:
> On 12/28/2014 06:20 PM, Simon Horman wrote:
> >This makes the handing of the absence of actions or matches
> >symmetric with net_flow_get_flow().
> >
> >Signed-off-by: Simon Horman <simon.horman@netronome.com>
> >---
>
> Again thanks I actually just hit this with my rocker implementation
> so very timely fix. Same story here I'll roll it into the patch and
> submit it later today.
Thanks. I have hit a few more minor problems which I have fixes for.
What is the best way to handle them? Rebase them on v1 of your patchset
and post them for review if they are still relevant?
^ permalink raw reply
* Re: [PATCH/RFC flow-net-next 04/10] net: flow: Add counters to flows
From: Simon Horman @ 2015-01-05 2:10 UTC (permalink / raw)
To: Arad, Ronen; +Cc: Fastabend, John R, netdev@vger.kernel.org
In-Reply-To: <E4CD12F19ABA0C4D8729E087A761DC3505DD0E24@ORSMSX101.amr.corp.intel.com>
On Mon, Dec 29, 2014 at 07:31:41AM +0000, Arad, Ronen wrote:
>
>
> >-----Original Message-----
> >From: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org] On
> >Behalf Of Simon Horman
> >Sent: Monday, December 29, 2014 4:16 AM
> >To: Fastabend, John R; netdev@vger.kernel.org
> >Cc: Simon Horman
> >Subject: [PATCH/RFC flow-net-next 04/10] net: flow: Add counters to flows
> >
> >It may be useful for hardware flow table support for counters to be exposed
> >via the flow API. One possible use case of this is for Open vSwitch to use
> >the flow API in conjunction with its existing datapath flow management
> >scheme which in a nutshell treats the datapath as a cache that times out
> >idle entries.
> >
> >This patch exposes optionally exposes three counters:
> >- Number of packets that have matched a flow
> >- Number of bytes of packets that have matched a flow
> >- The time in ms when the flow was last hit
> >
> >Inspired by the flow counters present in Open Flow.
> >
> >Signed-off-by: Simon Horman <simon.horman@netronome.com>
> >
> >---
> >
> >Compile tested only
> >---
> > include/uapi/linux/if_flow.h | 24 ++++++++++++++++++++++++
> > net/core/flow_table.c | 27 +++++++++++++++++++++++++++
> > 2 files changed, 51 insertions(+)
> >
> >diff --git a/include/uapi/linux/if_flow.h b/include/uapi/linux/if_flow.h
> >index 28da45b..18214ea 100644
> >--- a/include/uapi/linux/if_flow.h
> >+++ b/include/uapi/linux/if_flow.h
> >@@ -127,6 +127,9 @@
> > * [NET_FLOW_ATTR_PRIORITY]
> > * [NET_FLOW_ATTR_IDLE_TIMEOUT]
> > * [NET_FLOW_ATTR_HARD_TIMEOUT]
> >+ * [NET_FLOW_ATTR_BYTE_COUNT]
> >+ * [NET_FLOW_ATTR_PACKET_COUNT]
> >+ * [NET_FLOW_ATTR_LAST_USED]
> > * [NET_FLOW_ATTR_MATCHES]
> > * [NET_FLOW_FIELD_REF]
> > * [NET_FLOW_FIELD_REF]
> >@@ -153,6 +156,9 @@
> > * [NET_FLOW_ATTR_PRIORITY]
> > * [NET_FLOW_ATTR_IDLE_TIMEOUT]
> > * [NET_FLOW_ATTR_HARD_TIMEOUT]
> >+ * [NET_FLOW_ATTR_BYTE_COUNT]
> >+ * [NET_FLOW_ATTR_PACKET_COUNT]
> >+ * [NET_FLOW_ATTR_LAST_USED]
> > * [NET_FLOW_MATCHES]
> > * [NET_FLOW_FIELD_REF]
> > * [NET_FLOW_FIELD_REF]
> >@@ -365,6 +371,9 @@ enum {
> > * @idle_timeout idle timeout of flow in seconds. Zero for no timeout.
> > * @hard_timeout timeout of flow regardless of use in seconds.
> > * Zero for no timeout.
> >+ * @byte_count bytes recieved
> >+ * @byte_count packets recieved
> >+ * @last_used time of most recent use (msec since system initialisation)
> > *
> > * Flows must match all entries in match set.
> > */
> >@@ -374,6 +383,9 @@ struct net_flow_flow {
> > int priority;
> > __u32 idle_timeout;
> > __u32 hard_timeout;
> >+ __u64 byte_count;
> >+ __u64 packet_count;
> >+ __u64 last_used;
> > struct net_flow_field_ref *matches;
> > struct net_flow_action *actions;
> > };
> >@@ -414,6 +426,9 @@ enum {
> > NET_FLOW_ATTR_ACTIONS,
> > NET_FLOW_ATTR_IDLE_TIMEOUT,
> > NET_FLOW_ATTR_HARD_TIMEOUT,
> >+ NET_FLOW_ATTR_BYTE_COUNT,
> >+ NET_FLOW_ATTR_PACKET_COUNT,
> >+ NET_FLOW_ATTR_LAST_USED,
> > __NET_FLOW_ATTR_MAX,
> > };
> > #define NET_FLOW_ATTR_MAX (__NET_FLOW_ATTR_MAX - 1)
> >@@ -465,6 +480,15 @@ enum {
> >
> > /* Table supports idle timeout of flows */
> > NET_FLOW_TABLE_F_HARD_TIMEOUT = (1 << 1),
> >+
> >+ /* Table supports byte counter for flows */
> >+ NET_FLOW_TABLE_F_BYTE_COUNT = (1 << 2),
> >+
> >+ /* Table supports packet counter for flows */
> >+ NET_FLOW_TABLE_F_PACKET_COUNT = (1 << 3),
> >+
> >+ /* Table supports last used counter for flows */
> >+ NET_FLOW_TABLE_F_PACKET_LAST_USED = (1 << 4),
> > };
> >
> > #if 0
> >diff --git a/net/core/flow_table.c b/net/core/flow_table.c
> >index 89ba9bc..070e646 100644
> >--- a/net/core/flow_table.c
> >+++ b/net/core/flow_table.c
> >@@ -54,6 +54,9 @@ struct nla_policy net_flow_flow_policy[NET_FLOW_ATTR_MAX +
> >1] = {
> > [NET_FLOW_ATTR_PRIORITY] = { .type = NLA_U32 },
> > [NET_FLOW_ATTR_IDLE_TIMEOUT] = { .type = NLA_U32 },
> > [NET_FLOW_ATTR_HARD_TIMEOUT] = { .type = NLA_U32 },
> >+ [NET_FLOW_ATTR_BYTE_COUNT] = { .type = NLA_U64 },
> >+ [NET_FLOW_ATTR_PACKET_COUNT] = { .type = NLA_U64 },
> >+ [NET_FLOW_ATTR_LAST_USED] = { .type = NLA_U64 },
> > [NET_FLOW_ATTR_MATCHES] = { .type = NLA_NESTED },
> > [NET_FLOW_ATTR_ACTIONS] = { .type = NLA_NESTED },
> > };
> >@@ -206,6 +209,16 @@ int net_flow_put_flow(struct sk_buff *skb, struct
> >net_flow_flow *flow)
> > nla_put_u32(skb, NET_FLOW_ATTR_HARD_TIMEOUT, flow->hard_timeout))
> > goto flows_put_failure;
> >
> >+ if (flow->byte_count &&
> >+ nla_put_u32(skb, NET_FLOW_ATTR_BYTE_COUNT, flow->byte_count))
> >+ goto flows_put_failure;
> >+ if (flow->packet_count &&
> >+ nla_put_u32(skb, NET_FLOW_ATTR_PACKET_COUNT, flow->packet_count))
> >+ goto flows_put_failure;
> >+ if (flow->last_used &&
> >+ nla_put_u32(skb, NET_FLOW_ATTR_LAST_USED, flow->last_used))
> >+ goto flows_put_failure;
> >+
> The flow byte_count, packet_count, and last_used fields are defined as __u64 and related netlink attributes are of type NLA_U64 but nla_put_u32() is used to add them to the netlink msg.
Thanks, I will fix that up by using nla_put_u64().
> > matches = nla_nest_start(skb, NET_FLOW_ATTR_MATCHES);
> > if (!matches)
> > goto flows_put_failure;
> >@@ -536,6 +549,13 @@ static int net_flow_get_flow(struct net_flow_flow *flow,
> >struct nlattr *attr)
> > if (f[NET_FLOW_ATTR_HARD_TIMEOUT])
> > flow->hard_timeout = nla_get_u32(f[NET_FLOW_ATTR_HARD_TIMEOUT]);
> >
> >+ if (f[NET_FLOW_ATTR_BYTE_COUNT])
> >+ flow->byte_count = nla_get_u64(f[NET_FLOW_ATTR_BYTE_COUNT]);
> >+ if (f[NET_FLOW_ATTR_PACKET_COUNT])
> >+ flow->packet_count = nla_get_u64(f[NET_FLOW_ATTR_PACKET_COUNT]);
> >+ if (f[NET_FLOW_ATTR_LAST_USED])
> >+ flow->last_used = nla_get_u64(f[NET_FLOW_ATTR_LAST_USED]);
> >+
> > flow->matches = NULL;
> > flow->actions = NULL;
> >
> >@@ -1386,6 +1406,13 @@ static int net_flow_table_cmd_flows(struct sk_buff
> >*recv_skb,
> > if (this.hard_timeout)
> > used_features |= NET_FLOW_TABLE_F_HARD_TIMEOUT;
> >
> >+ if (this.byte_count)
> >+ used_features |= NET_FLOW_TABLE_F_BYTE_COUNT;
> >+ if (this.packet_count)
> >+ used_features |= NET_FLOW_TABLE_F_PACKET_COUNT;
> >+ if (this.last_used)
> >+ used_features |= NET_FLOW_TABLE_F_PACKET_LAST_USED;
> >+
> > err = net_flow_table_check_features(dev, this.table_id,
> > used_features);
> > if (err)
> >--
> >2.1.3
> >
> >--
> >To unsubscribe from this list: send the line "unsubscribe netdev" in
> >the body of a message to majordomo@vger.kernel.org
> >More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH/RFC flow-net-next 02/10] net: flow: Add features to tables
From: Simon Horman @ 2015-01-05 2:18 UTC (permalink / raw)
To: Cong Wang; +Cc: John Fastabend, netdev
In-Reply-To: <CAHA+R7NmfUpYcKfW_Gck2HaANH3OQk-9BAYZCXnBtGO1eV13xg@mail.gmail.com>
On Mon, Dec 29, 2014 at 03:03:39PM -0800, Cong Wang wrote:
> On Sun, Dec 28, 2014 at 6:15 PM, Simon Horman
> <simon.horman@netronome.com> wrote:
> > +static struct net_flow_table *net_flow_table_get_table(struct net_device *dev,
> > + int table_uid)
> > +{
> > + struct net_flow_table **tables;
> > + int i;
> > +
> > + tables = net_flow_get_tables(dev);
> > + if (IS_ERR(tables))
> > + return ERR_PTR(PTR_ERR(tables));
>
> Seriously? :)
I was looking for a way to handle the type of tables being different
to the return type of net_flow_table_get_table().
Would you recommend a cast?
return (struct net_flow_table *)tables;
^ permalink raw reply
* Re: [PATCH net-next v1 0/7] net: extend ethtool link mode bitmaps to 48 bits
From: Ben Hutchings @ 2015-01-05 2:30 UTC (permalink / raw)
To: Maciej Żenczykowski
Cc: David Decotigny, Amir Vadai, Florian Fainelli, Linux NetDev,
Linux Kernel Mailing List, linux-api, David Decotigny,
David S. Miller, Jason Wang, Michael S. Tsirkin, Herbert Xu,
Al Viro, Masatake YAMATO, Xi Wang, Neil Horman, WANG Cong,
Flavio Leitner, Tom Gundersen, Jiri Pirko, Vlad Yasevich,
Eric W. Biederman, Saeed Mahameed, Venkata Duvvuru, Govindaraj
In-Reply-To: <CAHo-Ooxi8V_58b456vePY9_7ChuBe0jxEVHvGkGvRBpAR744yA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1240 bytes --]
On Mon, 2015-01-05 at 01:34 +0100, Maciej Żenczykowski wrote:
> >> I can send updates to other drivers, even though it's rather pointless
> >> to update 1G drivers at this point for example. Please let me know,
> >> but I'd prefer to do this in follow-up patches outside this first
> >> patch series.
> > [...]
> >
> > They should be changed to ensure they reject setting any of the high
> > advertising flags, but it's not urgent.
>
> if old drivers advertised a get/set_bits function while new drivers
> advertised a get/set_new_bits function,
> you could not updated any old drivers, and simply take care of
> rejecting invalid bits in core, by calling set_new_bits if provided,
> if not, rejecting bad bits and calling set_bits if no bad bits were
> set.
We've never checked that the reserved fields are zero before, and I
think there are still drivers that don't fully validate the existing 32
bits. So while I think drivers should fully validate the advertising
flags, userland generally can't assume they do. And therefore I don't
think it's worth adding complexity to the ethtool core that only partly
fixes this.
Ben.
--
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
^ permalink raw reply
* Re: [PATCH] brcmfmac: avoid duplicated suspend/resume operation
From: Fu, Zhonghui @ 2015-01-05 2:34 UTC (permalink / raw)
To: Arend van Spriel
Cc: brudley, Franky Lin, meuleman, kvalo, linville, pieterpg,
hdegoede, wens, linux-wireless, brcm80211-dev-list, netdev,
linux-kernel
In-Reply-To: <54A3C837.6040400@broadcom.com>
Hi Arend,
Where to find your patch for this?
Thanks,
Zhonghui
On 2014/12/31 17:56, Arend van Spriel wrote:
> On 12/31/14 09:20, Fu, Zhonghui wrote:
>> From e34419970a07bfcd365f9c66bdfa552188a0cd26 Mon Sep 17 00:00:00 2001
>> From: Zhonghui Fu<zhonghui.fu@linux.intel.com>
>> Date: Mon, 29 Dec 2014 21:25:31 +0800
>> Subject: [PATCH] brcmfmac: avoid duplicated suspend/resume operation
>>
>> WiFi chip has 2 SDIO functions, and PM core will trigger
>> twice suspend/resume operations for one WiFi chip to do
>> the same things. This patch avoid this case.
>
> We have a patch queued up for this as well, but this one looks good enough although I personally prefer container_of() instead of dev_to_sdio_func().
>
> Acked-by: Arend van Spriel <arend@broadcom.com>
>> Signed-off-by: Zhonghui Fu<zhonghui.fu@linux.intel.com>
>> ---
>> drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c | 19 +++++++++++++++++--
>> 1 files changed, 17 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
>> index 3c06e93..eee7818 100644
>> --- a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
>> +++ b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
>> @@ -1139,11 +1139,18 @@ void brcmf_sdio_wowl_config(struct device *dev, bool enabled)
>> static int brcmf_ops_sdio_suspend(struct device *dev)
>> {
>> struct brcmf_bus *bus_if = dev_get_drvdata(dev);
>> - struct brcmf_sdio_dev *sdiodev = bus_if->bus_priv.sdio;
>> + struct brcmf_sdio_dev *sdiodev;
>> mmc_pm_flag_t sdio_flags;
>> + struct sdio_func *func = dev_to_sdio_func(dev);
>>
>> brcmf_dbg(SDIO, "Enter\n");
>>
>> + if (func->num == 2) {
>> + return 0;
>> + }
>> +
>> + sdiodev = bus_if->bus_priv.sdio;
>> +
>> atomic_set(&sdiodev->suspend, true);
>>
>> if (sdiodev->wowl_enabled) {
>> @@ -1164,9 +1171,17 @@ static int brcmf_ops_sdio_suspend(struct device *dev)
>> static int brcmf_ops_sdio_resume(struct device *dev)
>> {
>> struct brcmf_bus *bus_if = dev_get_drvdata(dev);
>> - struct brcmf_sdio_dev *sdiodev = bus_if->bus_priv.sdio;
>> + struct brcmf_sdio_dev *sdiodev;
>> + struct sdio_func *func = dev_to_sdio_func(dev);
>>
>> brcmf_dbg(SDIO, "Enter\n");
>> +
>> + if (func->num == 2) {
>> + return 0;
>> + }
>> +
>> + sdiodev = bus_if->bus_priv.sdio;
>> +
>> if (sdiodev->pdata->oob_irq_supported)
>> disable_irq_wake(sdiodev->pdata->oob_irq_nr);
>> brcmf_sdio_wd_timer(sdiodev->bus, BRCMF_WD_POLL_MS);
>> -- 1.7.1
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] brcmfmac: avoid duplicated suspend/resume operation
From: Fu, Zhonghui @ 2015-01-05 2:37 UTC (permalink / raw)
To: Sergei Shtylyov, brudley, Arend van Spriel, Franky Lin, meuleman,
kvalo, linville, pieterpg, hdegoede, wens, linux-wireless,
brcm80211-dev-list, netdev, linux-kernel
In-Reply-To: <54A3DC80.1080505@cogentembedded.com>
Hi Sergei,
You are right, I will apply your advice in next version of this patch.
Thanks,
Zhonghui
On 2014/12/31 19:22, Sergei Shtylyov wrote:
> Hello.
>
> On 12/31/2014 11:20 AM, Fu, Zhonghui wrote:
>
>> From e34419970a07bfcd365f9c66bdfa552188a0cd26 Mon Sep 17 00:00:00 2001
>> From: Zhonghui Fu <zhonghui.fu@linux.intel.com>
>> Date: Mon, 29 Dec 2014 21:25:31 +0800
>> Subject: [PATCH] brcmfmac: avoid duplicated suspend/resume operation
>
>> WiFi chip has 2 SDIO functions, and PM core will trigger
>> twice suspend/resume operations for one WiFi chip to do
>> the same things. This patch avoid this case.
>
>> Signed-off-by: Zhonghui Fu <zhonghui.fu@linux.intel.com>
>> ---
>> drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c | 19 +++++++++++++++++--
>> 1 files changed, 17 insertions(+), 2 deletions(-)
>
>> diff --git a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
>> index 3c06e93..eee7818 100644
>> --- a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
>> +++ b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
>> @@ -1139,11 +1139,18 @@ void brcmf_sdio_wowl_config(struct device *dev, bool enabled)
>> static int brcmf_ops_sdio_suspend(struct device *dev)
>> {
>> struct brcmf_bus *bus_if = dev_get_drvdata(dev);
>> - struct brcmf_sdio_dev *sdiodev = bus_if->bus_priv.sdio;
>> + struct brcmf_sdio_dev *sdiodev;
>> mmc_pm_flag_t sdio_flags;
>> + struct sdio_func *func = dev_to_sdio_func(dev);
>>
>> brcmf_dbg(SDIO, "Enter\n");
>>
>> + if (func->num == 2) {
>> + return 0;
>> + }
>
> {} not needed.
>
> [...]
>> @@ -1164,9 +1171,17 @@ static int brcmf_ops_sdio_suspend(struct device *dev)
>> static int brcmf_ops_sdio_resume(struct device *dev)
>> {
>> struct brcmf_bus *bus_if = dev_get_drvdata(dev);
>> - struct brcmf_sdio_dev *sdiodev = bus_if->bus_priv.sdio;
>> + struct brcmf_sdio_dev *sdiodev;
>> + struct sdio_func *func = dev_to_sdio_func(dev);
>>
>> brcmf_dbg(SDIO, "Enter\n");
>> +
>> + if (func->num == 2) {
>> + return 0;
>> + }
>
> Same here.
>
> [...]
>
> WBR, Sergei
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH net-next 0/3] swdev: add IPv4 routing offload
From: David Miller @ 2015-01-05 3:17 UTC (permalink / raw)
To: sfeldma; +Cc: netdev, jiri, john.fastabend, tgraf, jhs, andy, roopa
In-Reply-To: <1420169361-31767-1-git-send-email-sfeldma@gmail.com>
From: sfeldma@gmail.com
Date: Thu, 1 Jan 2015 19:29:18 -0800
> This patch set adds L3 routing offload support for IPv4 routes. The idea is to
> mirror routes installed in the kernel's FIB down to a hardware switch device to
> offload the data forwarding path for L3. Only the data forwarding path is
> intercepted. Control and management of the kernel's FIB remains with the
> kernel.
It looks like the design for this is still under discussion and that
new patches of whatever is decided upon will be forthcoming
eventually.
Can I ask you guys a huge favor? DO NOT quote the entire patch when
discussing these changes.
The thread for patch #1 was so time consuming to scan and read in
patchwork because you guys did this.
I know it takes a little bit more work to select and delete the patch
content in the quoted area, but you really have to do this because
otherwise it is a huge burden for reviewers trying to follow the
conversation.
Thanks.
^ permalink raw reply
* Re: [PATCH] net: ethernet: cpsw: fix hangs with interrupts
From: David Miller @ 2015-01-05 3:19 UTC (permalink / raw)
To: balbi; +Cc: mugunthanvnm, yegorslists, linux-omap, netdev, stable
In-Reply-To: <1420236959-32444-1-git-send-email-balbi@ti.com>
From: Felipe Balbi <balbi@ti.com>
Date: Fri, 2 Jan 2015 16:15:59 -0600
> The CPSW IP implements pulse-signaled interrupts. Due to
> that we must write a correct, pre-defined value to the
> CPDMA_MACEOIVECTOR register so the controller generates
> a pulse on the correct IRQ line to signal the End Of
> Interrupt.
>
> The way the driver is written today, all four IRQ lines
> are requested using the same IRQ handler and, because of
> that, we could fall into situations where a TX IRQ fires
> but we tell the controller that we ended an RX IRQ (or
> vice-versa). This situation triggers an IRQ storm on the
> reserved IRQ 127 of INTC which will in turn call ack_bad_irq()
> which will, then, print a ton of:
...
> Reported-by: Yegor Yefremov <yegorslists@googlemail.com>
> Fixes: 510a1e7 (drivers: net: davinci_cpdma: acknowledge interrupt properly)
> Cc: <stable@vger.kernel.org> # v3.9+
> Signed-off-by: Felipe Balbi <balbi@ti.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] GMAC: fix simple_return.cocci warnings
From: David Miller @ 2015-01-05 3:20 UTC (permalink / raw)
To: joe
Cc: fengguang.wu, roger.chen, kbuild-all, peppe.cavallaro, netdev,
linux-kernel
In-Reply-To: <1420246005.23591.7.camel@perches.com>
From: Joe Perches <joe@perches.com>
Date: Fri, 02 Jan 2015 16:46:45 -0800
> On Sat, 2015-01-03 at 08:25 +0800, kbuild test robot wrote:
>> drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c:425:1-4: WARNING: end returns can be simpified
>>
>> Simplify a trivial if-return sequence. Possibly combine with a
>> preceding function call.
>> Generated by: scripts/coccinelle/misc/simple_return.cocci
>>
>> CC: Roger Chen <roger.chen@rock-chips.com>
>> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
>> ---
>>
>> dwmac-rk.c | 6 +-----
>> 1 file changed, 1 insertion(+), 5 deletions(-)
>>
>> --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
>> +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
>> @@ -422,11 +422,7 @@ static int rk_gmac_init(struct platform_
>> if (ret)
>> return ret;
>>
>> - ret = gmac_clk_enable(bsp_priv, true);
>> - if (ret)
>> - return ret;
>> -
>> - return 0;
>> + return gmac_clk_enable(bsp_priv, true);
>
> I think this change is not particularly better.
>
> When the pattern is multiply repeated like:
...
> I think it's better to not change the last
> test in the sequence just to minimize overall
> line count.
I think it's a wash and that both ways are about the same to me.
I won't apply this, sorry.
^ permalink raw reply
* Re: [PATCH net-next 0/4] Geneve Cleanups
From: David Miller @ 2015-01-05 3:22 UTC (permalink / raw)
To: jesse; +Cc: netdev
In-Reply-To: <1420251965-44794-1-git-send-email-jesse@nicira.com>
From: Jesse Gross <jesse@nicira.com>
Date: Fri, 2 Jan 2015 18:26:01 -0800
> Much of the basis for the Geneve code comes from VXLAN. However,
> Geneve is quite a bit simpler than VXLAN and so this cleans up a
> lot of the infrastruction - particularly around locking - where the
> extra complexity is not necessary.
I like it, series applied, thanks Jesse.
^ permalink raw reply
* Re: [PATCH 1/1 linux-next] hp100: simplify hp100_module_init
From: David Miller @ 2015-01-05 3:23 UTC (permalink / raw)
To: fabf; +Cc: linux-kernel, perex, netdev
In-Reply-To: <1420292656-14429-1-git-send-email-fabf@skynet.be>
From: Fabian Frederick <fabf@skynet.be>
Date: Sat, 3 Jan 2015 14:44:16 +0100
> -Avoid double goto and directly return err where possible.
> -Remove unused labels which fixes:
>
> drivers/net/ethernet/hp/hp100.c:3047:2: warning: label
> 'out3' defined but not used [-Wunused-label]
>
> Signed-off-by: Fabian Frederick <fabf@skynet.be>
> ---
> This is untested.
Having a sole lone return statement that all flows of control
branch to makes the code easier to audit, than to have a huge
block where each return statement has to be audited independently
for potential cleanups.
Added to the fact that this patch is completely untested, I'm
not applying this, sorry.
^ permalink raw reply
* Re: [PATCH net-next] enic: reconfigure resources for kdump crash kernel
From: David Miller @ 2015-01-05 3:24 UTC (permalink / raw)
To: _govind; +Cc: netdev, ssujith, benve
In-Reply-To: <1420293944-7614-1-git-send-email-_govind@gmx.com>
From: Govindarajulu Varadarajan <_govind@gmx.com>
Date: Sat, 3 Jan 2015 19:35:44 +0530
> When running in kdump kernel, reduce number of resources used by the driver.
> This will enable NIC to operate in low memory kdump kernel environment.
>
> Also change the driver version to .83
>
> Signed-off-by: Govindarajulu Varadarajan <_govind@gmx.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH net-next] qlcnic: Fix dump_skb output
From: David Miller @ 2015-01-05 3:24 UTC (permalink / raw)
To: joe; +Cc: shahed.shaikh, netdev, linux-kernel
In-Reply-To: <1420336216.2619.9.camel@perches.com>
From: Joe Perches <joe@perches.com>
Date: Sat, 03 Jan 2015 17:50:16 -0800
> Use normal facilities to avoid printing each byte
> on a separate line.
>
> Now emits at KERN_DEBUG instead of KERN_INFO.
>
> Signed-off-by: Joe Perches <joe@perches.com>
This looks fine, applied, thanks Joe.
^ permalink raw reply
* Re: linux-next: build failure after merge of the net-next tree
From: Stephen Rothwell @ 2015-01-05 3:36 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-next, linux-kernel, richardcochran,
jeffrey.t.kirsher
In-Reply-To: <20150103.144530.1032237292364564169.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 792 bytes --]
Hi David,
On Sat, 03 Jan 2015 14:45:30 -0500 (EST) David Miller <davem@davemloft.net> wrote:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Sat, 3 Jan 2015 09:11:01 +1100
>
> > After merging the net-next tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > drivers/net/ethernet/mellanox/mlx4/en_clock.c: In function 'mlx4_en_init_timestamp':
> > drivers/net/ethernet/mellanox/mlx4/en_clock.c:249:2: error: implicit declaration of function 'CLOCKSOURCE_MASK' [-Werror=implicit-function-declaration]
> > mdev->cycles.mask = CLOCKSOURCE_MASK(48);
>
> Stephen please let me know if this failure is persisting.
All the ones I reported are fixed, thanks.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ 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