* Re: [V2 PATCH 3/9] macvtap: zerocopy: put page when fail to get all requested user pages
From: Shirley Ma @ 2012-05-15 17:33 UTC (permalink / raw)
To: Jason Wang; +Cc: eric.dumazet, mst, netdev, linux-kernel, ebiederm, davem
In-Reply-To: <20120502034157.11782.66606.stgit@amd-6168-8-1.englab.nay.redhat.com>
On Wed, 2012-05-02 at 11:41 +0800, Jason Wang wrote:
> When get_user_pages_fast() fails to get all requested pages, we could
> not use
> kfree_skb() to free it as it has not been put in the skb fragments. So
> we need
> to call put_page() instead.
>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
> ---
> drivers/net/macvtap.c | 6 ++++--
> 1 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
> index 7cb2684..9ab182a 100644
> --- a/drivers/net/macvtap.c
> +++ b/drivers/net/macvtap.c
> @@ -531,9 +531,11 @@ static int zerocopy_sg_from_iovec(struct sk_buff
> *skb, const struct iovec *from,
> size = ((base & ~PAGE_MASK) + len + ~PAGE_MASK) >>
> PAGE_SHIFT;
> num_pages = get_user_pages_fast(base, size, 0,
> &page[i]);
> if ((num_pages != size) ||
> - (num_pages > MAX_SKB_FRAGS -
> skb_shinfo(skb)->nr_frags))
> - /* put_page is in skb free */
> + (num_pages > MAX_SKB_FRAGS -
> skb_shinfo(skb)->nr_frags)) {
> + for (i = 0; i < num_pages; i++)
> + put_page(page[i]);
> return -EFAULT;
> + }
> truesize = size * PAGE_SIZE;
> skb->data_len += len;
> skb->len += len;
Good catch. I don't know why I thought put_page would be called in
skb_free for these pages which hadn't been added to skb frags before. :(
thanks
Shirley
^ permalink raw reply
* Re: [PATCH net-next V1 1/8] net/mlx4: Address build warnings on set but not used variables
From: David Miller @ 2012-05-15 17:38 UTC (permalink / raw)
To: ogerlitz; +Cc: roland, netdev, yevgenyp
In-Reply-To: <1337066690-2248-2-git-send-email-ogerlitz@mellanox.com>
From: Or Gerlitz <ogerlitz@mellanox.com>
Date: Tue, 15 May 2012 10:24:43 +0300
> - err = mlx4_cmd_imm(dev, mac, &out_param, RES_MAC,
> - RES_OP_RESERVE_AND_MAP, MLX4_CMD_FREE_RES,
> - MLX4_CMD_TIME_CLASS_A, MLX4_CMD_WRAPPED);
> + (void) mlx4_cmd_imm(dev, mac, &out_param, RES_MAC,
> + RES_OP_RESERVE_AND_MAP, MLX4_CMD_FREE_RES,
> + MLX4_CMD_TIME_CLASS_A, MLX4_CMD_WRAPPED);
Please stop wasting my time. This is not the correct way to indent
functions that have arguments on multiple lines.
I'll say it one more time:
The first character must line up with the column right after
the openning parenthesis on the first line.
This means you DO NOT use only TAB characters and indent the thing
into the solar system like you have above.
Instead you use TAB and SPACE characters, as needed, to line it up
properly, like so:
func(arg1, arg2,
arg3, arg4);
^ permalink raw reply
* Re: [PATCH 3/3] usbnet: fix skb traversing races during unlink(v1)
From: David Miller @ 2012-05-15 17:42 UTC (permalink / raw)
To: tom.leiming-Re5JQEeQqe8AvxtiuMwx3w
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
netdev-u79uwXL29TY76Z2rM5mHXA, linux-usb-u79uwXL29TY76Z2rM5mHXA,
huajun.li.lee-Re5JQEeQqe8AvxtiuMwx3w, oneukum-l3A5Bk7waGM,
stable-DgEjT+Ai2ygdnm+yROfE0A
In-Reply-To: <20120503090450.41704527@tom-ThinkPad-T410>
From: Ming Lei <tom.leiming-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Date: Thu, 3 May 2012 09:04:50 +0800
>>From a87ff961f0a5d50223bd084dfac4fe5ce84f3913 Mon Sep 17 00:00:00 2001
> From: Ming Lei <tom.leiming-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Date: Thu, 26 Apr 2012 11:33:46 +0800
> Subject: [PATCH] usbnet: fix skb traversing races during unlink(v2)
>
> Commit 4231d47e6fe69f061f96c98c30eaf9fb4c14b96d(net/usbnet: avoid
> recursive locking in usbnet_stop()) fixes the recursive locking
> problem by releasing the skb queue lock before unlink, but may
> cause skb traversing races:
> - after URB is unlinked and the queue lock is released,
> the refered skb and skb->next may be moved to done queue,
> even be released
> - in skb_queue_walk_safe, the next skb is still obtained
> by next pointer of the last skb
> - so maybe trigger oops or other problems
>
> This patch extends the usage of entry->state to describe 'start_unlink'
> state, so always holding the queue(rx/tx) lock to change the state if
> the referd skb is in rx or tx queue because we need to know if the
> refered urb has been started unlinking in unlink_urbs.
>
> The other part of this patch is based on Huajun's patch:
> always traverse from head of the tx/rx queue to get skb which is
> to be unlinked but not been started unlinking.
>
> Signed-off-by: Huajun Li <huajun.li.lee-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Ming Lei <tom.leiming-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Applied.
--
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] cdc_ether: add Novatel USB551L device IDs for FLAG_WWAN
From: David Miller @ 2012-05-15 17:42 UTC (permalink / raw)
To: oliver-GvhC2dPhHPQdnm+yROfE0A
Cc: dcbw-H+wXaHxf7aLQT0dZR+AlfA, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-usb-u79uwXL29TY76Z2rM5mHXA, stable-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <201205071623.56396.oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org>
From: Oliver Neukum <oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org>
Date: Mon, 7 May 2012 16:23:56 +0200
> Am Montag, 7. Mai 2012, 16:24:51 schrieb Dan Williams:
>> Needs to be tagged with FLAG_WWAN, which since it has generic
>> descriptors, won't happen if we don't override the generic
>> driver info.
>>
>> Cc: Oliver Neukum <oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org>
>> Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>> Signed-off-by: Dan Williams <dcbw-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
> Acked-by: Oliver Neukum <oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org>
Applied.
--
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] pch_gbe: fix transmit races
From: David Miller @ 2012-05-15 17:43 UTC (permalink / raw)
To: eric.dumazet; +Cc: andy.cress, netdev
In-Reply-To: <1337023566.8512.622.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 14 May 2012 21:26:06 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> Andy reported pch_gbe triggered "NETDEV WATCHDOG" errors.
>
> May 11 11:06:09 kontron kernel: WARNING: at net/sched/sch_generic.c:261
> dev_watchdog+0x1ec/0x200() (Not tainted)
> May 11 11:06:09 kontron kernel: Hardware name: N/A
> May 11 11:06:09 kontron kernel: NETDEV WATCHDOG: eth0 (pch_gbe):
> transmit queue 0 timed out
>
> It seems pch_gbe has a racy tx path (races with TX completion path)
>
> Remove tx_queue_lock lock since it has no purpose, we must use tx_lock
> instead.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Reported-by: Andy Cress <andy.cress@us.kontron.com>
> Tested-by: Andy Cress <andy.cress@us.kontron.com>
Applied.
^ permalink raw reply
* Re: [V2 PATCH 4/9] macvtap: zerocopy: set SKBTX_DEV_ZEROCOPY only when skb is built successfully
From: Shirley Ma @ 2012-05-15 17:44 UTC (permalink / raw)
To: Jason Wang; +Cc: eric.dumazet, mst, netdev, linux-kernel, ebiederm, davem
In-Reply-To: <20120502034206.11782.91643.stgit@amd-6168-8-1.englab.nay.redhat.com>
On Wed, 2012-05-02 at 11:42 +0800, Jason Wang wrote:
> Current the SKBTX_DEV_ZEROCOPY is set unconditionally after
> zerocopy_sg_from_iovec(), this would lead NULL pointer when macvtap
> fails to build zerocopy skb because destructor_arg was not
> initialized. Solve this by set this flag after the skb were built
> successfully.
I thought this flag was needed for zerocopy skb free even in err case.
I've checked it back again, it's OK to move the flag after the skb
successfully built. Or we can fix it by modify skb free with
destructor_arg NULL check as below:
...
skb_release_data() {
...
if (skb_shinfo(skb)->tx_flags & SKBTX_DEV_ZEROCOPY) {
struct ubuf_info *uarg;
uarg = skb_shinfo(skb)->destructor_arg;
if (uarg && uarg->callback)
uarg->callback(uarg);
}
...
}
Thanks
Shirley
^ permalink raw reply
* Re: [PATCH] dummy: documentation is stale
From: David Miller @ 2012-05-15 17:44 UTC (permalink / raw)
To: alan; +Cc: netdev
In-Reply-To: <20120514135724.23177.91808.stgit@bluebook>
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
Date: Mon, 14 May 2012 14:57:31 +0100
> From: Alan Cox <alan@linux.intel.com>
>
> dummy0/1/2 names are always used and there are options to set multiple
> dummy devices. Remove the obsolete text
>
> Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=42865
> Signed-off-by: Alan Cox <alan@linux.intel.com>
Applied, thanks Alan.
^ permalink raw reply
* Re: [RFC net-next 0/2] net: Use net_<level>_ratelimit
From: David Miller @ 2012-05-15 17:45 UTC (permalink / raw)
To: joe-6d6DIl74uiNBDgjK7y7TUQ
Cc: dev-yBygre7rU0TnMu66kgdUjQ, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
coreteam-Cap9r6Oaw4JrovVCs/uTlw, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-decnet-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sctp-u79uwXL29TY76Z2rM5mHXA,
netfilter-u79uwXL29TY76Z2rM5mHXA,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <cover.1336981915.git.joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
From: Joe Perches <joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
Date: Mon, 14 May 2012 00:56:24 -0700
> net_ratelimit() like __ratelimit() is too easy to misuse.
>
> Add simplifying macros similar to pr_<level>_ratelimited
> that combines the test of net_ratelimit and logging.
>
> Joe Perches (2):
> net: Add net_ratelimited_function and net_<level>_ratelimited macros
> net: Convert net_ratelimit uses to net_<level>_ratelimited
These look fine to me so I've applied them to net-next and am
sanity checking the build right now.
Thanks Joe.
^ permalink raw reply
* Re: [RFC net-next 0/2] net: Use net_<level>_ratelimit
From: Joe Perches @ 2012-05-15 17:59 UTC (permalink / raw)
To: David Miller
Cc: dev-yBygre7rU0TnMu66kgdUjQ, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
coreteam-Cap9r6Oaw4JrovVCs/uTlw, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-decnet-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sctp-u79uwXL29TY76Z2rM5mHXA,
netfilter-u79uwXL29TY76Z2rM5mHXA,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20120515.134531.530903973750646107.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Tue, 2012-05-15 at 13:45 -0400, David Miller wrote:
> From: Joe Perches <joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
> Date: Mon, 14 May 2012 00:56:24 -0700
>
> > net_ratelimit() like __ratelimit() is too easy to misuse.
> >
> > Add simplifying macros similar to pr_<level>_ratelimited
> > that combines the test of net_ratelimit and logging.
> >
> > Joe Perches (2):
> > net: Add net_ratelimited_function and net_<level>_ratelimited macros
> > net: Convert net_ratelimit uses to net_<level>_ratelimited
>
> These look fine to me so I've applied them to net-next and am
> sanity checking the build right now.
OK, but fyi, there's a possible issue with !CONFIG_DEBUG
builds because these patches converted some uses of
if (net_ratelimit())
printk(KERN_DEBUG ...
to
net_dbg_ratelimited()
These messages are no longer emitted when DEBUG isn't defined
and not using dynamic_debug. I'm not sure that's a real
problem, but it's a difference.
I could produce a net_printk_ratelimited that would keep
the original behavior if necessary.
net_printk_ratelimited(KERN_DEBUG etc...)
cheers, Joe
^ permalink raw reply
* Re: [PATCH RFC] tun: experimental zero copy tx support
From: Shirley Ma @ 2012-05-15 18:00 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Eric Dumazet, Stephen Hemminger, David S. Miller, Joe Perches,
Jason Wang, netdev, linux-kernel, Ian.Campbell, kvm
In-Reply-To: <20120514193134.GA18366@redhat.com>
On Mon, 2012-05-14 at 22:31 +0300, Michael S. Tsirkin wrote:
> On Mon, May 14, 2012 at 09:21:47PM +0200, Eric Dumazet wrote:
> > On Mon, 2012-05-14 at 22:14 +0300, Michael S. Tsirkin wrote:
> >
> > > They seem to be in net-next, or did I miss something?
> >
> > Yes, you re-introduce in this patch some bugs already fixed in
> macvtap
>
> Could explain why I see some problems in testing :)
> Maybe common code should go into net/core?
> I couldn't decide whether the increase in kernel
> size is worth it.
Which problem you hit during testing?
The logic of zerocopy_sg_from_iovec should work well. Jason's fix made
the code more clear.
Thanks
Shirley
^ permalink raw reply
* Re: [RFC net-next 0/2] net: Use net_<level>_ratelimit
From: Johannes Berg @ 2012-05-15 18:03 UTC (permalink / raw)
To: Joe Perches
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netfilter-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-decnet-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sctp-u79uwXL29TY76Z2rM5mHXA,
coreteam-Cap9r6Oaw4JrovVCs/uTlw,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA, David Miller
In-Reply-To: <1337104765.7050.24.camel@joe2Laptop>
On Tue, 2012-05-15 at 10:59 -0700, Joe Perches wrote:
> On Tue, 2012-05-15 at 13:45 -0400, David Miller wrote:
> > From: Joe Perches <joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
> > Date: Mon, 14 May 2012 00:56:24 -0700
> >
> > > net_ratelimit() like __ratelimit() is too easy to misuse.
> > >
> > > Add simplifying macros similar to pr_<level>_ratelimited
> > > that combines the test of net_ratelimit and logging.
> > >
> > > Joe Perches (2):
> > > net: Add net_ratelimited_function and net_<level>_ratelimited macros
> > > net: Convert net_ratelimit uses to net_<level>_ratelimited
> >
> > These look fine to me so I've applied them to net-next and am
> > sanity checking the build right now.
>
> OK, but fyi, there's a possible issue with !CONFIG_DEBUG
> builds because these patches converted some uses of
> if (net_ratelimit())
> printk(KERN_DEBUG ...
> to
> net_dbg_ratelimited()
>
> These messages are no longer emitted when DEBUG isn't defined
> and not using dynamic_debug. I'm not sure that's a real
> problem, but it's a difference.
>
> I could produce a net_printk_ratelimited that would keep
> the original behavior if necessary.
>
> net_printk_ratelimited(KERN_DEBUG etc...)
Oops. Yes, please do that, mac80211 doesn't have DEBUG yet
johannes
^ permalink raw reply
* Re: [PATCH] Add the command to show the time stamping capabilities.
From: Ben Hutchings @ 2012-05-15 18:08 UTC (permalink / raw)
To: Richard Cochran
Cc: netdev, David Miller, Martin Porter, Jacob Keller, Jeff Kirsher,
John Ronciak, e1000-devel
In-Reply-To: <1333475903-8185-1-git-send-email-richardcochran@gmail.com>
Sorry for the delay in handling this.
I've applied this with a minor change: I renamed the long option to
--show-time-stamping, for consistency with other 'show' options and to
allow for future addition of other time stamping options.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* RE: [PATCH v3 4/7] ARM: davinci: net: davinci_emac: add OF support
From: Nori, Sekhar @ 2012-05-15 18:08 UTC (permalink / raw)
To: Heiko Schocher, davinci-linux-open-source@linux.davincidsp.com
Cc: linux-arm-kernel@lists.infradead.org,
devicetree-discuss@lists.ozlabs.org, netdev@vger.kernel.org,
Grant Likely, Wolfgang Denk, Anatoly Sivov
In-Reply-To: <1330945804-3379-5-git-send-email-hs@denx.de>
Hi Heiko,
On Mon, Mar 05, 2012 at 16:40:01, Heiko Schocher wrote:
> add of support for the davinci_emac driver.
>
> Signed-off-by: Heiko Schocher <hs@denx.de>
> Cc: davinci-linux-open-source@linux.davincidsp.com
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: devicetree-discuss@lists.ozlabs.org
> Cc: netdev@vger.kernel.org
> Cc: Grant Likely <grant.likely@secretlab.ca>
> Cc: Sekhar Nori <nsekhar@ti.com>
> Cc: Wolfgang Denk <wd@denx.de>
> Cc: Anatoly Sivov <mm05@mail.ru>
>
> ---
> - changes for v2:
> - add comment from Anatoly Sivov
> - fix typo in davinci_emac.txt
> - add comment from Grant Likely:
> - add prefix "ti,davinci-" to davinci specific property names
> - remove version property
> - use compatible name "ti,davinci-dm6460-emac"
> - use devm_kzalloc()
> - use of_match_ptr()
> - document all new properties
> - remove of_address_to_resource() and do not overwrite
> resource table
> - whitespace fixes
> - remove hw_ram_addr as it is not used in current
> board code
> - no changes for v3
>
> .../bindings/arm/davinci/davinci_emac.txt | 43 +++++++++
> drivers/net/ethernet/ti/davinci_emac.c | 94 +++++++++++++++++++-
> 2 files changed, 136 insertions(+), 1 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt
>
> diff --git a/Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt b/Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt
> new file mode 100644
> index 0000000..a7b0911
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/davinci/davinci_emac.txt
Since DaVinci EMAC driver may be used on platforms other than DaVinci (c6x,
OMAP), can we place the bindings documentation in bindings/net/?
> @@ -0,0 +1,43 @@
> +* Texas Instruments Davinci EMAC
> +
> +This file provides information, what the device node
> +for the davinci_emac interface contain.
s/contain/contains
> +
> +Required properties:
> +- compatible: "ti,davinci-dm6460-emac";
There is no device called dm6460. If you intend to only support
"version 2" of the EMAC IP at this time, you can use dm6467
(http://www.ti.com/product/tms320dm6467)
> +- reg: Offset and length of the register set for the device
> +- ti,davinci-ctrl-reg-offset: offset to control register
> +- ti,davinci-ctrl-mod-reg-offset: offset to control module register
> +- ti,davinci-ctrl-ram-offset: offset to control module ram
> +- ti,davinci-ctrl-ram-size: size of control module ram
> +- ti,davinci-rmii-en: use RMII
> +- ti,davinci-no-bd-ram: has the emac controller BD RAM
> +- phy-handle: Contains a phandle to an Ethernet PHY.
> + if not, davinci_emac driver defaults to 100/FULL
> +- interrupts: interrupt mapping for the davinci emac interrupts sources:
> + 4 sources: <Receive Threshold Interrupt
> + Receive Interrupt
> + Transmit Interrupt
> + Miscellaneous Interrupt>
> +- pinmux-handle: Contains a handle to configure the pinmux settings.
> +
> +Optional properties:
> +- local-mac-address : 6 bytes, mac address
> +
> +Example (enbw_cmc board):
> + eth0: emac@1e20000 {
> + compatible = "ti,davinci-dm6460-emac";
> + reg = <0x220000 0x4000>;
> + ti,davinci-ctrl-reg-offset = <0x3000>;
> + ti,davinci-ctrl-mod-reg-offset = <0x2000>;
> + ti,davinci-ctrl-ram-offset = <0>;
> + ti,davinci-ctrl-ram-size = <0x2000>;
> + local-mac-address = [ 00 00 00 00 00 00 ];
> + interrupts = <33
> + 34
> + 35
> + 36
> + >;
> + interrupt-parent = <&intc>;
> + pinmux-handle = <&emac_pins>;
> + };
> diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
> index 4fa0bcb..56e1c35 100644
> --- a/drivers/net/ethernet/ti/davinci_emac.c
> +++ b/drivers/net/ethernet/ti/davinci_emac.c
> @@ -58,6 +58,12 @@
> #include <linux/io.h>
> #include <linux/uaccess.h>
> #include <linux/davinci_emac.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/of_irq.h>
> +#include <linux/of_net.h>
> +
> +#include <mach/mux.h>
>
> #include <asm/irq.h>
> #include <asm/page.h>
> @@ -339,6 +345,9 @@ struct emac_priv {
> u32 rx_addr_type;
> atomic_t cur_tx;
> const char *phy_id;
> +#ifdef CONFIG_OF
> + struct device_node *phy_node;
> +#endif
> struct phy_device *phydev;
> spinlock_t lock;
> /*platform specific members*/
> @@ -1760,6 +1769,82 @@ static const struct net_device_ops emac_netdev_ops = {
> #endif
> };
>
> +#ifdef CONFIG_OF
> +static struct emac_platform_data
> + *davinci_emac_of_get_pdata(struct platform_device *pdev,
> + struct emac_priv *priv)
> +{
> + struct device_node *np;
> + struct device_node *pinmux_np;
> + struct emac_platform_data *pdata = NULL;
> + const u8 *mac_addr;
> + u32 data;
> + int ret;
> + int version;
> +
> + np = pdev->dev.of_node;
> + if (!np)
> + goto nodata;
> + else
> + version = EMAC_VERSION_2;
You could set pdata->version directly here.
> +
> + pdata = pdev->dev.platform_data;
> + if (!pdata) {
> + pdata = devm_kzalloc(&pdev->dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata)
> + goto nodata;
> + }
> + pdata->version = version;
> +
> + mac_addr = of_get_mac_address(np);
> + if (mac_addr)
> + memcpy(pdata->mac_addr, mac_addr, ETH_ALEN);
> +
> + ret = of_property_read_u32(np, "ti,davinci-ctrl-reg-offset", &data);
> + if (!ret)
> + pdata->ctrl_reg_offset = data;
> +
> + ret = of_property_read_u32(np, "ti,davinci-ctrl-mod-reg-offset",
> + &data);
> + if (!ret)
> + pdata->ctrl_mod_reg_offset = data;
> +
> + ret = of_property_read_u32(np, "ti,davinci-ctrl-ram-offset", &data);
> + if (!ret)
> + pdata->ctrl_ram_offset = data;
> +
> + ret = of_property_read_u32(np, "ti,davinci-ctrl-ram-size", &data);
> + if (!ret)
> + pdata->ctrl_ram_size = data;
> +
> + ret = of_property_read_u32(np, "ti,davinci-rmii-en", &data);
> + if (!ret)
> + pdata->rmii_en = data;
> +
> + ret = of_property_read_u32(np, "ti,davinci-no-bd-ram", &data);
> + if (!ret)
> + pdata->no_bd_ram = data;
> +
> + priv->phy_node = of_parse_phandle(np, "phy-handle", 0);
> + if (!priv->phy_node)
> + pdata->phy_id = "";
> +
> + pinmux_np = of_parse_phandle(np, "pinmux-handle", 0);
> + if (pinmux_np)
> + davinci_cfg_reg_of(pinmux_np);
This is a DaVinci specific pinmux function and this
driver can be used in non-DaVinci platforms like C6x
and OMAP. So, it will not be correct to call a DaVinci
specific function here.
Can you drop the pinmux from this patch for now? On DaVinci,
for pinmux, we need to migrate to drivers/pinctrl/ as well.
Doing this will also make this patch independent of the rest
of this series can even be merged separately. Can you please
make these changes and resend just this patch?
> +
> + pdev->dev.platform_data = pdata;
> +nodata:
> + return pdata;
> +}
> +#else
> +static struct emac_platform_data
> + *davinci_emac_of_get_pdata(struct platform_device *pdev,
> + struct emac_priv *priv)
> +{
> + return pdev->dev.platform_data;
> +}
> +#endif
> /**
> * davinci_emac_probe: EMAC device probe
> * @pdev: The DaVinci EMAC device that we are removing
> @@ -1803,7 +1888,7 @@ static int __devinit davinci_emac_probe(struct platform_device *pdev)
>
> spin_lock_init(&priv->lock);
>
> - pdata = pdev->dev.platform_data;
> + pdata = davinci_emac_of_get_pdata(pdev, priv);
> if (!pdata) {
> dev_err(&pdev->dev, "no platform data\n");
> rc = -ENODEV;
> @@ -2013,6 +2098,12 @@ static const struct dev_pm_ops davinci_emac_pm_ops = {
> .resume = davinci_emac_resume,
> };
>
> +static const struct of_device_id davinci_emac_of_match[] = {
> + {.compatible = "ti,davinci-dm6460-emac", },
This needs to be ti,davinci-dm6467-emac as well.
Thanks,
Sekhar
^ permalink raw reply
* Re: [RFC net-next 0/2] net: Use net_<level>_ratelimit
From: David Miller @ 2012-05-15 18:13 UTC (permalink / raw)
To: johannes-cdvu00un1VgdHxzADdlk8Q
Cc: dev-yBygre7rU0TnMu66kgdUjQ, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
coreteam-Cap9r6Oaw4JrovVCs/uTlw, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-decnet-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sctp-u79uwXL29TY76Z2rM5mHXA,
netfilter-u79uwXL29TY76Z2rM5mHXA,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA,
joe-6d6DIl74uiNBDgjK7y7TUQ
In-Reply-To: <1337105028.15553.3.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Date: Tue, 15 May 2012 20:03:48 +0200
> Oops. Yes, please do that, mac80211 doesn't have DEBUG yet
If you want debugging messages you would turn on dynamic_debug
via sysctl or whatever, not define DEBUG in your sources.
I don't think we should add yet another interface just to get
KERN_DEBUG in there.
^ permalink raw reply
* Re: [RFC net-next 0/2] net: Use net_<level>_ratelimit
From: David Miller @ 2012-05-15 18:14 UTC (permalink / raw)
To: joe-6d6DIl74uiNBDgjK7y7TUQ
Cc: dev-yBygre7rU0TnMu66kgdUjQ, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
coreteam-Cap9r6Oaw4JrovVCs/uTlw, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-decnet-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sctp-u79uwXL29TY76Z2rM5mHXA,
netfilter-u79uwXL29TY76Z2rM5mHXA,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1337104765.7050.24.camel@joe2Laptop>
From: Joe Perches <joe-6d6DIl74uiNBDgjK7y7TUQ@public.gmane.org>
Date: Tue, 15 May 2012 10:59:25 -0700
> I could produce a net_printk_ratelimited that would keep
> the original behavior if necessary.
>
> net_printk_ratelimited(KERN_DEBUG etc...)
I don't think it's worth the hassle, we'd rather get people
into the habit of using dynamic_debug.
^ permalink raw reply
* Re: [RFC net-next 0/2] net: Use net_<level>_ratelimit
From: Johannes Berg @ 2012-05-15 18:21 UTC (permalink / raw)
To: David Miller
Cc: dev-yBygre7rU0TnMu66kgdUjQ, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
coreteam-Cap9r6Oaw4JrovVCs/uTlw, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-decnet-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sctp-u79uwXL29TY76Z2rM5mHXA,
netfilter-u79uwXL29TY76Z2rM5mHXA,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA,
joe-6d6DIl74uiNBDgjK7y7TUQ
In-Reply-To: <20120515.141348.892964316296815698.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Tue, 2012-05-15 at 14:13 -0400, David Miller wrote:
> From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
> Date: Tue, 15 May 2012 20:03:48 +0200
>
> > Oops. Yes, please do that, mac80211 doesn't have DEBUG yet
>
> If you want debugging messages you would turn on dynamic_debug
> via sysctl or whatever, not define DEBUG in your sources.
>
> I don't think we should add yet another interface just to get
> KERN_DEBUG in there.
But don't you have to do something in the sources to actually get
dynamic_debug enabled? I'm concerned this will make mac80211 debugging
inconsistent - the normal bits are just printk() still, and the
rate-limited bits need some special enabling? That seems odd.
johannes
^ permalink raw reply
* Re: [RFC net-next 0/2] net: Use net_<level>_ratelimit
From: David Miller @ 2012-05-15 18:24 UTC (permalink / raw)
To: johannes-cdvu00un1VgdHxzADdlk8Q
Cc: dev-yBygre7rU0TnMu66kgdUjQ, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
coreteam-Cap9r6Oaw4JrovVCs/uTlw, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-decnet-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sctp-u79uwXL29TY76Z2rM5mHXA,
netfilter-u79uwXL29TY76Z2rM5mHXA,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA,
joe-6d6DIl74uiNBDgjK7y7TUQ
In-Reply-To: <1337106094.15553.5.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Date: Tue, 15 May 2012 20:21:34 +0200
> On Tue, 2012-05-15 at 14:13 -0400, David Miller wrote:
>> From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
>> Date: Tue, 15 May 2012 20:03:48 +0200
>>
>> > Oops. Yes, please do that, mac80211 doesn't have DEBUG yet
>>
>> If you want debugging messages you would turn on dynamic_debug
>> via sysctl or whatever, not define DEBUG in your sources.
>>
>> I don't think we should add yet another interface just to get
>> KERN_DEBUG in there.
>
> But don't you have to do something in the sources to actually get
> dynamic_debug enabled? I'm concerned this will make mac80211 debugging
> inconsistent - the normal bits are just printk() still, and the
> rate-limited bits need some special enabling? That seems odd.
You can turn them all off or on with a simple flip of a boolean switch
at run-time. Or, alternatively, you can turn them on or off in a
finer grained manner with other run-time facilities.
There should be a transition away from explicit KERN_DEBUG.
^ permalink raw reply
* Re: [RFC net-next 0/2] net: Use net_<level>_ratelimit
From: Johannes Berg @ 2012-05-15 18:27 UTC (permalink / raw)
To: Joe Perches
Cc: dev-yBygre7rU0TnMu66kgdUjQ, netfilter-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-decnet-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sctp-u79uwXL29TY76Z2rM5mHXA,
coreteam-Cap9r6Oaw4JrovVCs/uTlw,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA, David Miller
In-Reply-To: <1337104765.7050.24.camel@joe2Laptop>
On Tue, 2012-05-15 at 10:59 -0700, Joe Perches wrote:
> OK, but fyi, there's a possible issue with !CONFIG_DEBUG
> builds because these patches converted some uses of
> if (net_ratelimit())
> printk(KERN_DEBUG ...
> to
> net_dbg_ratelimited()
>
> These messages are no longer emitted when DEBUG isn't defined
> and not using dynamic_debug. I'm not sure that's a real
> problem, but it's a difference.
>
> I could produce a net_printk_ratelimited that would keep
> the original behavior if necessary.
>
> net_printk_ratelimited(KERN_DEBUG etc...)
Btw, what would the difference be to just plain printk_ratelimited()?
johannes
^ permalink raw reply
* Re: [RFC net-next 0/2] net: Use net_<level>_ratelimit
From: Johannes Berg @ 2012-05-15 18:29 UTC (permalink / raw)
To: David Miller
Cc: dev-yBygre7rU0TnMu66kgdUjQ, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
coreteam-Cap9r6Oaw4JrovVCs/uTlw, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-decnet-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sctp-u79uwXL29TY76Z2rM5mHXA,
netfilter-u79uwXL29TY76Z2rM5mHXA,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA,
joe-6d6DIl74uiNBDgjK7y7TUQ
In-Reply-To: <20120515.142405.633851408201128056.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Tue, 2012-05-15 at 14:24 -0400, David Miller wrote:
> > But don't you have to do something in the sources to actually get
> > dynamic_debug enabled? I'm concerned this will make mac80211 debugging
> > inconsistent - the normal bits are just printk() still, and the
> > rate-limited bits need some special enabling? That seems odd.
>
> You can turn them all off or on with a simple flip of a boolean switch
> at run-time. Or, alternatively, you can turn them on or off in a
> finer grained manner with other run-time facilities.
>
> There should be a transition away from explicit KERN_DEBUG.
I support that, but I think it's confusing to have things mixed. Also,
we seem to have printk_ratelimit(), so I'd prefer to have that used in
mac80211 instead until everything there moves over to newer facilities.
johannes
^ permalink raw reply
* Re: [PATCH v3 6/6] net: sh_eth: use NAPI
From: Francois Romieu @ 2012-05-15 18:29 UTC (permalink / raw)
To: David Miller; +Cc: yoshihiro.shimoda.uh, netdev, linux-sh
In-Reply-To: <20120515.130552.119728053706080493.davem@davemloft.net>
David Miller <davem@davemloft.net> :
> From: "Shimoda, Yoshihiro" <yoshihiro.shimoda.uh@renesas.com>
[...]
> > I will modify the code as the following. Is it correct?
> >
> > if (txfree_num) {
> > netif_tx_lock(ndev);
> > if (netif_queue_stopped(ndev))
> > netif_wake_queue(ndev);
> > netif_tx_unlock(ndev);
> > }
>
> Yes, and then you don't need that private lock in the start_xmit()
> method at all, since that method runs with the tx_lock held.
I agree that the lock should go but:
1. something must be done to prevent sh_eth_txfree() being called
at the same time from the xmit and poll handlers
2. while netif_tx locking above provides an implicit memory barrier,
there won't be one in sh_eth_start_xmit once the lock is removed.
mdp->dirty_tx changes may thus go unnoticed in sh_eth_start_xmit
--
Ueimor
^ permalink raw reply
* Re: [RFC net-next 0/2] net: Use net_<level>_ratelimit
From: David Miller @ 2012-05-15 18:29 UTC (permalink / raw)
To: johannes-cdvu00un1VgdHxzADdlk8Q
Cc: dev-yBygre7rU0TnMu66kgdUjQ, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
coreteam-Cap9r6Oaw4JrovVCs/uTlw, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-decnet-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sctp-u79uwXL29TY76Z2rM5mHXA,
netfilter-u79uwXL29TY76Z2rM5mHXA,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA,
joe-6d6DIl74uiNBDgjK7y7TUQ
In-Reply-To: <1337106430.15553.6.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Date: Tue, 15 May 2012 20:27:10 +0200
> On Tue, 2012-05-15 at 10:59 -0700, Joe Perches wrote:
>
>> OK, but fyi, there's a possible issue with !CONFIG_DEBUG
>> builds because these patches converted some uses of
>> if (net_ratelimit())
>> printk(KERN_DEBUG ...
>> to
>> net_dbg_ratelimited()
>>
>> These messages are no longer emitted when DEBUG isn't defined
>> and not using dynamic_debug. I'm not sure that's a real
>> problem, but it's a difference.
>>
>> I could produce a net_printk_ratelimited that would keep
>> the original behavior if necessary.
>>
>> net_printk_ratelimited(KERN_DEBUG etc...)
>
> Btw, what would the difference be to just plain printk_ratelimited()?
printk_ratelimited() drops a local ratelimit cookie into each call-site,
whereas we have a global one for the networking which these new interfaces
use.
Joe explained this completely in his 0/2 patch posting.
^ permalink raw reply
* Re: [RFC net-next 0/2] net: Use net_<level>_ratelimit
From: David Miller @ 2012-05-15 18:30 UTC (permalink / raw)
To: johannes-cdvu00un1VgdHxzADdlk8Q
Cc: dev-yBygre7rU0TnMu66kgdUjQ, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
coreteam-Cap9r6Oaw4JrovVCs/uTlw, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-decnet-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sctp-u79uwXL29TY76Z2rM5mHXA,
netfilter-u79uwXL29TY76Z2rM5mHXA,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA,
joe-6d6DIl74uiNBDgjK7y7TUQ
In-Reply-To: <1337106548.15553.8.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Date: Tue, 15 May 2012 20:29:08 +0200
> On Tue, 2012-05-15 at 14:24 -0400, David Miller wrote:
>
>> > But don't you have to do something in the sources to actually get
>> > dynamic_debug enabled? I'm concerned this will make mac80211 debugging
>> > inconsistent - the normal bits are just printk() still, and the
>> > rate-limited bits need some special enabling? That seems odd.
>>
>> You can turn them all off or on with a simple flip of a boolean switch
>> at run-time. Or, alternatively, you can turn them on or off in a
>> finer grained manner with other run-time facilities.
>>
>> There should be a transition away from explicit KERN_DEBUG.
>
> I support that, but I think it's confusing to have things mixed. Also,
> we seem to have printk_ratelimit(), so I'd prefer to have that used in
> mac80211 instead until everything there moves over to newer facilities.
No, you don't want that, it's different from the networking ratelimit
mechanism. Joe explained this, and I just explaing it to you once
again in another reply.
^ permalink raw reply
* Re: [RFC net-next 0/2] net: Use net_<level>_ratelimit
From: Johannes Berg @ 2012-05-15 18:40 UTC (permalink / raw)
To: David Miller
Cc: dev-yBygre7rU0TnMu66kgdUjQ, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
coreteam-Cap9r6Oaw4JrovVCs/uTlw, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-decnet-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sctp-u79uwXL29TY76Z2rM5mHXA,
netfilter-u79uwXL29TY76Z2rM5mHXA,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA,
joe-6d6DIl74uiNBDgjK7y7TUQ
In-Reply-To: <20120515.142922.1434224550630736456.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On Tue, 2012-05-15 at 14:29 -0400, David Miller wrote:
> From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
> Date: Tue, 15 May 2012 20:27:10 +0200
>
> > On Tue, 2012-05-15 at 10:59 -0700, Joe Perches wrote:
> >
> >> OK, but fyi, there's a possible issue with !CONFIG_DEBUG
> >> builds because these patches converted some uses of
> >> if (net_ratelimit())
> >> printk(KERN_DEBUG ...
> >> to
> >> net_dbg_ratelimited()
> >>
> >> These messages are no longer emitted when DEBUG isn't defined
> >> and not using dynamic_debug. I'm not sure that's a real
> >> problem, but it's a difference.
> >>
> >> I could produce a net_printk_ratelimited that would keep
> >> the original behavior if necessary.
> >>
> >> net_printk_ratelimited(KERN_DEBUG etc...)
> >
> > Btw, what would the difference be to just plain printk_ratelimited()?
>
> printk_ratelimited() drops a local ratelimit cookie into each call-site,
> whereas we have a global one for the networking which these new interfaces
> use.
>
> Joe explained this completely in his 0/2 patch posting.
I don't see that explicitly mentioned, but it doesn't matter much
anyway.
In the mac80211 case, messages are warnings/hints to the user, we just
don't want them to flood the logs too much. I'd rather have that kind of
change (limit cookie per callsite) in the rate limiting semantics than
the change in the when it gets printed at all.
I simply feel that obscuring the debugging even further wouldn't be a
good thing to do right now. I'd rather have somebody convert all of it
to the new debugging infrastructure but that seems a lot more effort
than changing these back to something that isn't impacted by dynamic
printk.
johannes
^ permalink raw reply
* Re: [RFC net-next 0/2] net: Use net_<level>_ratelimit
From: David Miller @ 2012-05-15 18:51 UTC (permalink / raw)
To: johannes-cdvu00un1VgdHxzADdlk8Q
Cc: dev-yBygre7rU0TnMu66kgdUjQ, linux-nfs-u79uwXL29TY76Z2rM5mHXA,
coreteam-Cap9r6Oaw4JrovVCs/uTlw, netdev-u79uwXL29TY76Z2rM5mHXA,
linux-decnet-user-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-sctp-u79uwXL29TY76Z2rM5mHXA,
netfilter-u79uwXL29TY76Z2rM5mHXA,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA,
joe-6d6DIl74uiNBDgjK7y7TUQ
In-Reply-To: <1337107245.15553.14.camel-8upI4CBIZJIJvtFkdXX2HixXY32XiHfO@public.gmane.org>
From: Johannes Berg <johannes-cdvu00un1VgdHxzADdlk8Q@public.gmane.org>
Date: Tue, 15 May 2012 20:40:45 +0200
> In the mac80211 case, messages are warnings/hints to the user, we just
> don't want them to flood the logs too much. I'd rather have that kind of
> change (limit cookie per callsite) in the rate limiting semantics than
> the change in the when it gets printed at all.
Then they aren't KERN_DEBUG, they are KERN_INFO or KERN_WARN.
^ permalink raw reply
* [PATCH] xfrm: Convert several xfrm policy match functions to bool.
From: David Miller @ 2012-05-15 19:05 UTC (permalink / raw)
To: netdev
xfrm_selector_match
xfrm_sec_ctx_match
__xfrm4_selector_match
__xfrm6_selector_match
Signed-off-by: David S. Miller <davem@davemloft.net>
---
include/net/xfrm.h | 12 ++++++------
net/xfrm/xfrm_policy.c | 27 ++++++++++++++-------------
2 files changed, 20 insertions(+), 19 deletions(-)
diff --git a/include/net/xfrm.h b/include/net/xfrm.h
index 1cb32bf..e0a55df 100644
--- a/include/net/xfrm.h
+++ b/include/net/xfrm.h
@@ -886,15 +886,15 @@ __be16 xfrm_flowi_dport(const struct flowi *fl, const union flowi_uli *uli)
return port;
}
-extern int xfrm_selector_match(const struct xfrm_selector *sel,
- const struct flowi *fl,
- unsigned short family);
+extern bool xfrm_selector_match(const struct xfrm_selector *sel,
+ const struct flowi *fl,
+ unsigned short family);
#ifdef CONFIG_SECURITY_NETWORK_XFRM
/* If neither has a context --> match
* Otherwise, both must have a context and the sids, doi, alg must match
*/
-static inline int xfrm_sec_ctx_match(struct xfrm_sec_ctx *s1, struct xfrm_sec_ctx *s2)
+static inline bool xfrm_sec_ctx_match(struct xfrm_sec_ctx *s1, struct xfrm_sec_ctx *s2)
{
return ((!s1 && !s2) ||
(s1 && s2 &&
@@ -903,9 +903,9 @@ static inline int xfrm_sec_ctx_match(struct xfrm_sec_ctx *s1, struct xfrm_sec_ct
(s1->ctx_alg == s2->ctx_alg)));
}
#else
-static inline int xfrm_sec_ctx_match(struct xfrm_sec_ctx *s1, struct xfrm_sec_ctx *s2)
+static inline bool xfrm_sec_ctx_match(struct xfrm_sec_ctx *s1, struct xfrm_sec_ctx *s2)
{
- return 1;
+ return true;
}
#endif
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index 7661576..3c87a1c 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -56,7 +56,7 @@ static int xfrm_bundle_ok(struct xfrm_dst *xdst);
static struct xfrm_policy *__xfrm_policy_unlink(struct xfrm_policy *pol,
int dir);
-static inline int
+static inline bool
__xfrm4_selector_match(const struct xfrm_selector *sel, const struct flowi *fl)
{
const struct flowi4 *fl4 = &fl->u.ip4;
@@ -69,7 +69,7 @@ __xfrm4_selector_match(const struct xfrm_selector *sel, const struct flowi *fl)
(fl4->flowi4_oif == sel->ifindex || !sel->ifindex);
}
-static inline int
+static inline bool
__xfrm6_selector_match(const struct xfrm_selector *sel, const struct flowi *fl)
{
const struct flowi6 *fl6 = &fl->u.ip6;
@@ -82,8 +82,8 @@ __xfrm6_selector_match(const struct xfrm_selector *sel, const struct flowi *fl)
(fl6->flowi6_oif == sel->ifindex || !sel->ifindex);
}
-int xfrm_selector_match(const struct xfrm_selector *sel, const struct flowi *fl,
- unsigned short family)
+bool xfrm_selector_match(const struct xfrm_selector *sel, const struct flowi *fl,
+ unsigned short family)
{
switch (family) {
case AF_INET:
@@ -91,7 +91,7 @@ int xfrm_selector_match(const struct xfrm_selector *sel, const struct flowi *fl,
case AF_INET6:
return __xfrm6_selector_match(sel, fl);
}
- return 0;
+ return false;
}
static inline struct dst_entry *__xfrm_dst_lookup(struct net *net, int tos,
@@ -877,7 +877,8 @@ static int xfrm_policy_match(const struct xfrm_policy *pol,
u8 type, u16 family, int dir)
{
const struct xfrm_selector *sel = &pol->selector;
- int match, ret = -ESRCH;
+ int ret = -ESRCH;
+ bool match;
if (pol->family != family ||
(fl->flowi_mark & pol->mark.m) != pol->mark.v ||
@@ -1006,8 +1007,8 @@ static struct xfrm_policy *xfrm_sk_policy_lookup(struct sock *sk, int dir,
read_lock_bh(&xfrm_policy_lock);
if ((pol = sk->sk_policy[dir]) != NULL) {
- int match = xfrm_selector_match(&pol->selector, fl,
- sk->sk_family);
+ bool match = xfrm_selector_match(&pol->selector, fl,
+ sk->sk_family);
int err = 0;
if (match) {
@@ -2767,8 +2768,8 @@ EXPORT_SYMBOL_GPL(xfrm_audit_policy_delete);
#endif
#ifdef CONFIG_XFRM_MIGRATE
-static int xfrm_migrate_selector_match(const struct xfrm_selector *sel_cmp,
- const struct xfrm_selector *sel_tgt)
+static bool xfrm_migrate_selector_match(const struct xfrm_selector *sel_cmp,
+ const struct xfrm_selector *sel_tgt)
{
if (sel_cmp->proto == IPSEC_ULPROTO_ANY) {
if (sel_tgt->family == sel_cmp->family &&
@@ -2778,14 +2779,14 @@ static int xfrm_migrate_selector_match(const struct xfrm_selector *sel_cmp,
sel_cmp->family) == 0 &&
sel_tgt->prefixlen_d == sel_cmp->prefixlen_d &&
sel_tgt->prefixlen_s == sel_cmp->prefixlen_s) {
- return 1;
+ return true;
}
} else {
if (memcmp(sel_tgt, sel_cmp, sizeof(*sel_tgt)) == 0) {
- return 1;
+ return true;
}
}
- return 0;
+ return false;
}
static struct xfrm_policy * xfrm_migrate_policy_find(const struct xfrm_selector *sel,
--
1.7.7.6
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox