* Re: [PATCH 2/3] bridge: offload bridge port attributes to switch asic if feature flag set
From: Jiri Pirko @ 2014-12-05 7:38 UTC (permalink / raw)
To: roopa
Cc: sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen, linville,
nhorman, nicolas.dichtel, vyasevic, f.fainelli, buytenh, aviadr,
netdev, davem, shm, gospo
In-Reply-To: <1417746401-8140-3-git-send-email-roopa@cumulusnetworks.com>
Fri, Dec 05, 2014 at 03:26:40AM CET, roopa@cumulusnetworks.com wrote:
>From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
>This allows offloading to switch asic without having the user to set
>any flag. And this is done in the bridge driver to rollback kernel settings
>on hw offload failure if required in the future.
>
>With this, it also makes sure a notification goes out only after the
>attributes are set both in the kernel and hw.
>---
> net/bridge/br_netlink.c | 27 ++++++++++++++++++++++++++-
> 1 file changed, 26 insertions(+), 1 deletion(-)
>
>diff --git a/net/bridge/br_netlink.c b/net/bridge/br_netlink.c
>index 9f5eb55..ce173f0 100644
>--- a/net/bridge/br_netlink.c
>+++ b/net/bridge/br_netlink.c
>@@ -407,9 +407,21 @@ int br_setlink(struct net_device *dev, struct nlmsghdr *nlh)
> afspec, RTM_SETLINK);
> }
>
>+ if ((dev->features & NETIF_F_HW_SWITCH_OFFLOAD) &&
>+ dev->netdev_ops->ndo_bridge_setlink) {
>+ int ret = dev->netdev_ops->ndo_bridge_setlink(dev, nlh);
This (and I suspect other patches as well) has many issues which
are pointed out by scripts/checkpatch.pl sctipts. For example
here, there should be an empty line. Please run your patches by
this script before you send them.
>+ if (ret && ret != -EOPNOTSUPP) {
>+ /* XXX Fix this in the future to rollback
>+ * kernel settings and return error
>+ */
>+ br_warn(p->br, "error offloading bridge attributes "
>+ "on port %u(%s)\n", (unsigned int) p->port_no,
>+ p->dev->name);
>+ }
>+ }
>+
> if (err == 0)
> br_ifinfo_notify(RTM_NEWLINK, p);
>-
> out:
> return err;
> }
>@@ -433,6 +445,19 @@ int br_dellink(struct net_device *dev, struct nlmsghdr *nlh)
> err = br_afspec((struct net_bridge *)netdev_priv(dev), p,
> afspec, RTM_DELLINK);
>
>+ if (dev->features & NETIF_F_HW_SWITCH_OFFLOAD
>+ && dev->netdev_ops->ndo_bridge_setlink) {
>+ int ret = dev->netdev_ops->ndo_bridge_dellink(dev, nlh);
c&p issue, there should be check for dellink here.
>+ if (ret && ret != -EOPNOTSUPP) {
>+ /* XXX Fix this in the future to rollback
>+ * kernel settings and return error
>+ */
>+ br_warn(p->br, "error offloading bridge attributes "
>+ "on port %u(%s)\n", (unsigned int) p->port_no,
>+ p->dev->name);
>+ }
>+ }
>+
I agree with Scott that this code should be moved to rtnetlink.c
> return err;
> }
> static int br_validate(struct nlattr *tb[], struct nlattr *data[])
>--
>1.7.10.4
>
^ permalink raw reply
* Re: [PATCH v2 1/6] net-PPP: Replacement of a printk() call by pr_warn() in mppe_rekey()
From: Joe Perches @ 2014-12-05 7:41 UTC (permalink / raw)
To: Julia Lawall
Cc: SF Markus Elfring, Sergei Shtylyov, Paul Mackerras, linux-ppp,
netdev, Eric Dumazet, LKML, kernel-janitors
In-Reply-To: <alpine.DEB.2.02.1412050820290.2059@localhost6.localdomain6>
On Fri, 2014-12-05 at 08:21 +0100, Julia Lawall wrote:
> On Thu, 4 Dec 2014, Joe Perches wrote:
> > It's generally nicer to replace embedded function names
> > with "%s: ", __func__
> >
> > pr_warn("%s: cipher_encrypt failed\n", __func__);
>
> Doing so may potentially allow some strings to be shared, thus saving a
> little space. Perhaps not in this case, though.
It's not necessarily a code size savings in any case.
It can be, but the real benefits are stylistic
consistency and lack of mismatch between function
name and message.
If the code is refactored or copy/pasted into another
function, a moderately common defect is not modifying
the embedded function name in the message.
There may be some smallish savings if ever these
__func__ uses were converted to use %pf via some
internal standardized mechanism.
A negative to that approach is inlined functions would
take the function name of the parent not keep the
inlined function name.
^ permalink raw reply
* Re: [PATCH 1/3] netdev: introduce new NETIF_F_HW_SWITCH_OFFLOAD feature flag for switch device offloads
From: Jiri Pirko @ 2014-12-05 7:41 UTC (permalink / raw)
To: roopa
Cc: sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen, linville,
nhorman, nicolas.dichtel, vyasevic, f.fainelli, buytenh, aviadr,
netdev, davem, shm, gospo
In-Reply-To: <1417746401-8140-2-git-send-email-roopa@cumulusnetworks.com>
Fri, Dec 05, 2014 at 03:26:39AM CET, roopa@cumulusnetworks.com wrote:
>From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
>This is a generic high level feature flag for all switch asic features today.
>
>switch drivers set this flag on switch ports. Logical devices like
>bridge, bonds, vxlans can inherit this flag from their slaves/ports.
Can you please elaborate on how exactly would this inheritance look
like?
>
>I had to use SWITCH in the name to avoid ambiguity with other feature
>flags. But, since i have been harping about not calling it 'switch',
>I am welcome to any suggestions :)
>
>An alternative to using a feature flag is to use a IFF_HW_OFFLOAD
>in net_device_flags.
>---
> include/linux/netdev_features.h | 2 ++
> 1 file changed, 2 insertions(+)
>
>diff --git a/include/linux/netdev_features.h b/include/linux/netdev_features.h
>index 8e30685..68db1de 100644
>--- a/include/linux/netdev_features.h
>+++ b/include/linux/netdev_features.h
>@@ -66,6 +66,7 @@ enum {
> NETIF_F_HW_VLAN_STAG_FILTER_BIT,/* Receive filtering on VLAN STAGs */
> NETIF_F_HW_L2FW_DOFFLOAD_BIT, /* Allow L2 Forwarding in Hardware */
> NETIF_F_BUSY_POLL_BIT, /* Busy poll */
>+ NETIF_F_HW_SWITCH_OFFLOAD_BIT, /* HW switch offload */
>
> /*
> * Add your fresh new feature above and remember to update
>@@ -124,6 +125,7 @@ enum {
> #define NETIF_F_HW_VLAN_STAG_TX __NETIF_F(HW_VLAN_STAG_TX)
> #define NETIF_F_HW_L2FW_DOFFLOAD __NETIF_F(HW_L2FW_DOFFLOAD)
> #define NETIF_F_BUSY_POLL __NETIF_F(BUSY_POLL)
>+#define NETIF_F_HW_SWITCH_OFFLOAD __NETIF_F(HW_SWITCH_OFFLOAD)
>
> /* Features valid for ethtool to change */
> /* = all defined minus driver/device-class-related */
>--
>1.7.10.4
>
^ permalink raw reply
* Re: [PATCH iproute2] bridge link: add option 'self'
From: Jiri Pirko @ 2014-12-05 7:55 UTC (permalink / raw)
To: roopa
Cc: sfeldma, jhs, bcrl, tgraf, john.fastabend, stephen, linville,
nhorman, nicolas.dichtel, vyasevic, f.fainelli, buytenh, aviadr,
netdev, davem, shm, gospo
In-Reply-To: <1417746436-41023-1-git-send-email-roopa@cumulusnetworks.com>
Fri, Dec 05, 2014 at 03:27:16AM CET, roopa@cumulusnetworks.com wrote:
>From: Roopa Prabhu <roopa@cumulusnetworks.com>
>
>Currently self is set internally only if hwmode is set.
>This makes it necessary for the hw to have a mode.
>There is no hwmode really required to go to hardware. So, introduce
>self for anybody who wants to target hardware.
Signed-off line is missing.
Other than that, the patch looks fine.
Reviewed-by: Jiri Pirko <jiri@resnulli.us>
Feel free to add my review line to the repost.
>---
> bridge/link.c | 3 +++
> 1 file changed, 3 insertions(+)
>
>diff --git a/bridge/link.c b/bridge/link.c
>index 90d9e7f..2b86141 100644
>--- a/bridge/link.c
>+++ b/bridge/link.c
>@@ -321,6 +321,9 @@ static int brlink_modify(int argc, char **argv)
> "\"veb\".\n");
> exit(-1);
> }
>+ } else if (strcmp(*argv, "self") == 0) {
>+ NEXT_ARG();
>+ flags = BRIDGE_FLAGS_SELF;
> } else {
> usage();
> }
>--
>1.7.10.4
>
^ permalink raw reply
* Re: [PATCH v2 1/6] net-PPP: Replacement of a printk() call by pr_warn() in mppe_rekey()
From: Joe Perches @ 2014-12-05 7:57 UTC (permalink / raw)
To: SF Markus Elfring
Cc: Sergei Shtylyov, Paul Mackerras, linux-ppp, netdev, Eric Dumazet,
LKML, kernel-janitors, Julia Lawall
In-Reply-To: <54815C5F.8090702@users.sourceforge.net>
On Fri, 2014-12-05 at 08:18 +0100, SF Markus Elfring wrote:
> >>> It's generally nicer to replace embedded function names
> >>> with "%s: ", __func__
> >>>
> >>> pr_warn("%s: cipher_encrypt failed\n", __func__);
> >>
> >> Do you want that I send a third patch series for the fine-tuning of these parameters?
> >
> > If you want.
>
> Would "a committer" fix such a small source code adjustment also without a resend of
> a patch series?
Depends on the committer. Some might, most wouldn't.
drivers/net/ppp doesn't have a specific maintainer.
The networking maintainer generally asks for resends
of patches that don't suit his taste, but lots of
non-perfect patches still get applied there.
It's a process, and it's not immediate. Wait to see
if these get applied as-is. If the embedded function
name use, which is trivial, bothers you, send another
patch later on that changes it.
> Does it make sense to express such implementation details in the Linux coding
> style documentation more explicitly (besides the fact that this update suggestion
> was also triggered by a warning from the script "checkpatch.pl").
Probably not.
Overly formalized coding style rules are perhaps
more of a barrier to entry than most want.
^ permalink raw reply
* Re: [RESEND PATCH] net: introduce helper macra CMSG_FOREACH_HDR
From: Joe Perches @ 2014-12-05 8:02 UTC (permalink / raw)
To: Gu Zheng; +Cc: davem, netdev, linux-kernel
In-Reply-To: <54815B40.1050909@cn.fujitsu.com>
On Fri, 2014-12-05 at 15:14 +0800, Gu Zheng wrote:
> Introduce helper macra
macro
> CMSG_FOREACH_HDR as a wrapper of the enumerating
> cmsghdr from msghdr, just cleanup.
maybe better to use lower case "for_each_cmsg_hdr"
or some such.
checkpatch would recognize that too as long as it
uses "for_each".
> diff --git a/include/linux/socket.h b/include/linux/socket.h
[]
> @@ -94,6 +94,10 @@ struct cmsghdr {
> (cmsg)->cmsg_len <= (unsigned long) \
> ((mhdr)->msg_controllen - \
> ((char *)(cmsg) - (char *)(mhdr)->msg_control)))
> +#define CMSG_FOREACH_HDR(cmsg, msg) \
> + for (cmsg = CMSG_FIRSTHDR(msg); \
> + cmsg; \
> + cmsg = CMSG_NXTHDR(msg, cmsg))
^ permalink raw reply
* Re: [PATCH v2 1/6] net-PPP: Replacement of a printk() call by pr_warn() in mppe_rekey()
From: SF Markus Elfring @ 2014-12-05 8:04 UTC (permalink / raw)
To: Julia Lawall, Joe Perches
Cc: Sergei Shtylyov, Paul Mackerras, linux-ppp, netdev, Eric Dumazet,
LKML, kernel-janitors
In-Reply-To: <alpine.DEB.2.02.1412050726000.2059@localhost6.localdomain6>
> Markus, are you sure that you cannot use netdev_warn in this case?
No. - I did not become familiar enough with the software infrastructure around
the mppe_rekey() function.
I do not see so far how I could determine a pointer for the first parameter there.
The data structure "ppp_mppe_state" (which is referenced by the input variable
"state") does not contain corresponding context information, does it?
Regards,
Markus
^ permalink raw reply
* Re: [PATCH] net: ethernet: rocker: Add select to CONFIG_BRIDGE in Kconfig
From: Andreas Ruprecht @ 2014-12-05 8:28 UTC (permalink / raw)
To: David Miller
Cc: jim.epost, sfr, linux-next, linux-kernel, jiri, sfeldma, netdev
In-Reply-To: <20141204.202404.32587724475591669.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 766 bytes --]
> On 05.12.2014 05:24, David Miller wrote:
> Do not use select, please.
>
> You can only use select on leaf node Kconfig symbols, ie. those
> which do not have any dependencies whatsoever.
>
> Select does not recursively walk down the dependency chain turning
> things on for you when you say "select X".
>
Okay, sure, my bad for not looking that up properly.
If we change this into a "depends on", this should not be a problem,
right? If CONFIG_BRIDGE is selected as 'm', then CONFIG_ROCKER can only
be 'n' or 'm', if CONFIG_BRIDGE is set to 'y', it can be 'n', 'm' or 'y'.
This also means that the prompt associated with CONFIG_ROCKER will only
show up in menuconfig when CONFIG_BRIDGE has been enabled (either 'm' or
'y').
I've attached an updated patch.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-net-ethernet-rocker-Add-dependency-to-CONFIG_BRIDGE-.patch --]
[-- Type: text/x-patch; name="0001-net-ethernet-rocker-Add-dependency-to-CONFIG_BRIDGE-.patch", Size: 1439 bytes --]
From 931a36cc5ec67ec23ba2373d42840d968ed78120 Mon Sep 17 00:00:00 2001
From: Andreas Ruprecht <rupran@einserver.de>
Date: Thu, 4 Dec 2014 18:28:09 +0100
Subject: [PATCH] net: ethernet: rocker: Add dependency to CONFIG_BRIDGE in
Kconfig
In a configuration with CONFIG_BRIDGE set to 'm' and CONFIG_ROCKER
set to 'y', undefined references occur at link time:
> drivers/built-in.o: In function `rocker_port_fdb_learn_work':
> /home/jim/linux/drivers/net/ethernet/rocker/rocker.c:3014: undefined
> reference to `br_fdb_external_learn_del'
> /home/jim/linux/drivers/net/ethernet/rocker/rocker.c:3016: undefined
> reference to `br_fdb_external_learn_add'
This patch fixes these by declaring CONFIG_ROCKER as being dependent
on CONFIG_BRIDGE.
Reported-by: Jim Davis <jim.epost@gmail.com>
Signed-off-by: Andreas Ruprecht <rupran@einserver.de>
---
drivers/net/ethernet/rocker/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/rocker/Kconfig b/drivers/net/ethernet/rocker/Kconfig
index 11a850eab628..b9952ef040e4 100644
--- a/drivers/net/ethernet/rocker/Kconfig
+++ b/drivers/net/ethernet/rocker/Kconfig
@@ -17,7 +17,7 @@ if NET_VENDOR_ROCKER
config ROCKER
tristate "Rocker switch driver (EXPERIMENTAL)"
- depends on PCI && NET_SWITCHDEV
+ depends on PCI && NET_SWITCHDEV && BRIDGE
---help---
This driver supports Rocker switch device.
--
1.9.1
^ permalink raw reply related
* Re: [RESEND PATCH] net: introduce helper macra CMSG_FOREACH_HDR
From: Gu Zheng @ 2014-12-05 8:29 UTC (permalink / raw)
To: Joe Perches; +Cc: davem, netdev, linux-kernel
In-Reply-To: <1417766552.2721.45.camel@perches.com>
Hi Joe,
Thanks for your comment.
On 12/05/2014 04:02 PM, Joe Perches wrote:
> On Fri, 2014-12-05 at 15:14 +0800, Gu Zheng wrote:
>> Introduce helper macra
>
> macro
Ah~, it's a typo.
>
>> CMSG_FOREACH_HDR as a wrapper of the enumerating
>> cmsghdr from msghdr, just cleanup.
>
> maybe better to use lower case "for_each_cmsg_hdr"
> or some such.
But this will make it out of the ordinary, as the existed ones
are all upper.
David, what's your opinion?
Regards,
Gu
>
> checkpatch would recognize that too as long as it
> uses "for_each".
>
>> diff --git a/include/linux/socket.h b/include/linux/socket.h
> []
>> @@ -94,6 +94,10 @@ struct cmsghdr {
>> (cmsg)->cmsg_len <= (unsigned long) \
>> ((mhdr)->msg_controllen - \
>> ((char *)(cmsg) - (char *)(mhdr)->msg_control)))
>> +#define CMSG_FOREACH_HDR(cmsg, msg) \
>> + for (cmsg = CMSG_FIRSTHDR(msg); \
>> + cmsg; \
>> + cmsg = CMSG_NXTHDR(msg, cmsg))
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply
* Re: [PATCH] net: ethernet: rocker: Add select to CONFIG_BRIDGE in Kconfig
From: Jiri Pirko @ 2014-12-05 8:32 UTC (permalink / raw)
To: Andreas Ruprecht
Cc: David Miller, jim.epost, sfr, linux-next, linux-kernel, sfeldma,
netdev
In-Reply-To: <54816C93.2020009@rupran.de>
Fri, Dec 05, 2014 at 09:28:03AM CET, mail@rupran.de wrote:
>
>> On 05.12.2014 05:24, David Miller wrote:
>> Do not use select, please.
>>
>> You can only use select on leaf node Kconfig symbols, ie. those
>> which do not have any dependencies whatsoever.
>>
>> Select does not recursively walk down the dependency chain turning
>> things on for you when you say "select X".
>>
>
>Okay, sure, my bad for not looking that up properly.
>
>If we change this into a "depends on", this should not be a problem,
>right? If CONFIG_BRIDGE is selected as 'm', then CONFIG_ROCKER can only
>be 'n' or 'm', if CONFIG_BRIDGE is set to 'y', it can be 'n', 'm' or 'y'.
>
>This also means that the prompt associated with CONFIG_ROCKER will only
>show up in menuconfig when CONFIG_BRIDGE has been enabled (either 'm' or
>'y').
>
>I've attached an updated patch.
>From 931a36cc5ec67ec23ba2373d42840d968ed78120 Mon Sep 17 00:00:00 2001
>From: Andreas Ruprecht <rupran@einserver.de>
>Date: Thu, 4 Dec 2014 18:28:09 +0100
>Subject: [PATCH] net: ethernet: rocker: Add dependency to CONFIG_BRIDGE in
> Kconfig
>
>In a configuration with CONFIG_BRIDGE set to 'm' and CONFIG_ROCKER
>set to 'y', undefined references occur at link time:
>
>> drivers/built-in.o: In function `rocker_port_fdb_learn_work':
>> /home/jim/linux/drivers/net/ethernet/rocker/rocker.c:3014: undefined
>> reference to `br_fdb_external_learn_del'
>> /home/jim/linux/drivers/net/ethernet/rocker/rocker.c:3016: undefined
>> reference to `br_fdb_external_learn_add'
>
>This patch fixes these by declaring CONFIG_ROCKER as being dependent
>on CONFIG_BRIDGE.
>
>Reported-by: Jim Davis <jim.epost@gmail.com>
>Signed-off-by: Andreas Ruprecht <rupran@einserver.de>
Acked-by: Jiri Pirko <jiri@resnulli.us>
>---
> drivers/net/ethernet/rocker/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/net/ethernet/rocker/Kconfig b/drivers/net/ethernet/rocker/Kconfig
>index 11a850eab628..b9952ef040e4 100644
>--- a/drivers/net/ethernet/rocker/Kconfig
>+++ b/drivers/net/ethernet/rocker/Kconfig
>@@ -17,7 +17,7 @@ if NET_VENDOR_ROCKER
>
> config ROCKER
> tristate "Rocker switch driver (EXPERIMENTAL)"
>- depends on PCI && NET_SWITCHDEV
>+ depends on PCI && NET_SWITCHDEV && BRIDGE
> ---help---
> This driver supports Rocker switch device.
>
>--
>1.9.1
>
^ permalink raw reply
* Re: [PATCH v2 1/6] net-PPP: Replacement of a printk() call by pr_warn() in mppe_rekey()
From: Julia Lawall @ 2014-12-05 8:40 UTC (permalink / raw)
To: SF Markus Elfring
Cc: Julia Lawall, Joe Perches, Sergei Shtylyov, Paul Mackerras,
linux-ppp, netdev, Eric Dumazet, LKML, kernel-janitors
In-Reply-To: <54816700.6090501@users.sourceforge.net>
On Fri, 5 Dec 2014, SF Markus Elfring wrote:
> > Markus, are you sure that you cannot use netdev_warn in this case?
>
> No. - I did not become familiar enough with the software infrastructure around
> the mppe_rekey() function.
>
> I do not see so far how I could determine a pointer for the first parameter there.
> The data structure "ppp_mppe_state" (which is referenced by the input variable
> "state") does not contain corresponding context information, does it?
Indeed, I also don't see anything promising.
julia
^ permalink raw reply
* CAN presume-ack feature
From: Nikita Edward Baruzdin @ 2014-12-05 8:41 UTC (permalink / raw)
To: linux-can, netdev
In-Reply-To: <1417766390-4587-1-git-send-email-nebaruzdin@gmail.com>
Hello, all.
I just remembered about this small patch I promised to submit.
It corresponds to an earlier introduced change in SocketCAN subsystem, see
http://thread.gmane.org/gmane.linux.can/6110
^ permalink raw reply
* [PATCH] iproute2: Add support for CAN presume-ack feature
From: Nikita Edward Baruzdin @ 2014-12-05 8:41 UTC (permalink / raw)
To: linux-can, netdev
In-Reply-To: <1417768902-5404-1-git-send-email-nebaruzdin@gmail.com>
This patch makes CAN_CTRLMODE_PRESUME_ACK netlink feature configurable.
When enabled, the feature sets CAN controller in mode in which
acknowledgement absence is ignored.
Signed-off-by: Nikita Edward Baruzdin <nebaruzdin@gmail.com>
---
ip/iplink_can.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/ip/iplink_can.c b/ip/iplink_can.c
index 5b92426..fb50332 100644
--- a/ip/iplink_can.c
+++ b/ip/iplink_can.c
@@ -37,6 +37,7 @@ static void print_usage(FILE *f)
"\t[ one-shot { on | off } ]\n"
"\t[ berr-reporting { on | off } ]\n"
"\t[ fd { on | off } ]\n"
+ "\t[ presume-ack { on | off } ]\n"
"\n"
"\t[ restart-ms TIME-MS ]\n"
"\t[ restart ]\n"
@@ -99,6 +100,7 @@ static void print_ctrlmode(FILE *f, __u32 cm)
_PF(CAN_CTRLMODE_ONE_SHOT, "ONE-SHOT");
_PF(CAN_CTRLMODE_BERR_REPORTING, "BERR-REPORTING");
_PF(CAN_CTRLMODE_FD, "FD");
+ _PF(CAN_CTRLMODE_PRESUME_ACK, "PRESUME-ACK");
#undef _PF
if (cm)
fprintf(f, "%x", cm);
@@ -201,6 +203,10 @@ static int can_parse_opt(struct link_util *lu, int argc, char **argv,
NEXT_ARG();
set_ctrlmode("fd", *argv, &cm,
CAN_CTRLMODE_FD);
+ } else if (matches(*argv, "presume-ack") == 0) {
+ NEXT_ARG();
+ set_ctrlmode("presume-ack", *argv, &cm,
+ CAN_CTRLMODE_PRESUME_ACK);
} else if (matches(*argv, "restart") == 0) {
__u32 val = 1;
--
2.1.3
^ permalink raw reply related
* Re: [PATCH v2 1/6] net-PPP: Replacement of a printk() call by pr_warn() in mppe_rekey()
From: SF Markus Elfring @ 2014-12-05 8:49 UTC (permalink / raw)
To: Joe Perches
Cc: Sergei Shtylyov, Paul Mackerras, linux-ppp, netdev, Eric Dumazet,
LKML, kernel-janitors, Julia Lawall
In-Reply-To: <1417766255.2721.43.camel@perches.com>
> It's a process, and it's not immediate. Wait to see
> if these get applied as-is.
Thanks for your constructive feedback.
> If the embedded function name use, which is trivial, bothers you,
> send another patch later on that changes it.
Not really at the moment ...
I guess that I would prefer a general development of another semantic
patch approach according to your request with the topic "Finding embedded
function names?" a moment ago.
https://systeme.lip6.fr/pipermail/cocci/2014-December/001517.html
http://article.gmane.org/gmane.comp.version-control.coccinelle/4399
Regards,
Markus
^ permalink raw reply
* Re: Is this 32-bit NCM?y
From: Bjørn Mork @ 2014-12-05 9:42 UTC (permalink / raw)
To: Kevin Zhu
Cc: Enrico Mioso, Midge Shaojun Tan, Eli Britstein, Alex Strizhevsky,
youtux@gmail.com, linux-usb@vger.kernel.org,
netdev@vger.kernel.org
In-Reply-To: <54811670.5030703-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org>
Kevin Zhu <Mingying.Zhu-6C2+4RG2qWF0ubjbjo6WXg@public.gmane.org> writes:
> Regarding the location of NDP, it should be easy to fix. It can be added
> to the end of the NTB only after it's ready to send.
Yes, but this will require a bit of redesign. Note that this code is
shared with cdc_mbim, which might have to add multiple NDPs for
multiplexed sessions. In theory up to 512 different, but that is so
unlinkely that we can ignore it. We could set a fixed limit
significantly lower than that if necessary.
I'd really like to refactor this code to simply queue the skbs, creating
the linear NTB only when the queue is flushed. Then we'll have all the
info we need and can order the contents any way we want without adding
unnecessary padding.
> Regarding the
> concern to other devices, as there's a particular driver for Huawei
> devices in kernel, which is huawei_cdc_ncm, maybe we can just fix the TX
> function there to avoid breaking other devices.
Sure. That is definitely an alternative if we don't want to touch the
generic driver.
But making the generic driver flexible enough to accommodate any device
would be preferable. I do hope we can do that.
Bjørn
--
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
* [PATCH] net: fix the flow limitation computation
From: roy.qing.li @ 2014-12-05 9:48 UTC (permalink / raw)
To: netdev
From: Li RongQing <roy.qing.li@gmail.com>
Once RPS is enabled, the skb maybe enqueue to different CPU, so the
flow limitation computation should use the enqueued CPU, not the local
CPU
Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
---
net/core/dev.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 945bbd0..e70507d 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3250,7 +3250,7 @@ static int rps_ipi_queued(struct softnet_data *sd)
int netdev_flow_limit_table_len __read_mostly = (1 << 12);
#endif
-static bool skb_flow_limit(struct sk_buff *skb, unsigned int qlen)
+static bool skb_flow_limit(struct sk_buff *skb, unsigned int qlen, int cpu)
{
#ifdef CONFIG_NET_FLOW_LIMIT
struct sd_flow_limit *fl;
@@ -3260,7 +3260,7 @@ static bool skb_flow_limit(struct sk_buff *skb, unsigned int qlen)
if (qlen < (netdev_max_backlog >> 1))
return false;
- sd = this_cpu_ptr(&softnet_data);
+ sd = &per_cpu(softnet_data, cpu);
rcu_read_lock();
fl = rcu_dereference(sd->flow_limit);
@@ -3303,7 +3303,7 @@ static int enqueue_to_backlog(struct sk_buff *skb, int cpu,
rps_lock(sd);
qlen = skb_queue_len(&sd->input_pkt_queue);
- if (qlen <= netdev_max_backlog && !skb_flow_limit(skb, qlen)) {
+ if (qlen <= netdev_max_backlog && !skb_flow_limit(skb, qlen, cpu)) {
if (skb_queue_len(&sd->input_pkt_queue)) {
enqueue:
__skb_queue_tail(&sd->input_pkt_queue, skb);
--
2.1.0
^ permalink raw reply related
* [PATCH][net-next] net: avoid to call skb_queue_len again
From: roy.qing.li @ 2014-12-05 9:49 UTC (permalink / raw)
To: netdev
From: Li RongQing <roy.qing.li@gmail.com>
the queue length of sd->input_pkt_queue has been putted into qlen,
and impossible to change, since hold the lock
Signed-off-by: Li RongQing <roy.qing.li@gmail.com>
---
net/core/dev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 0814a56..b954400 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3297,7 +3297,7 @@ static int enqueue_to_backlog(struct sk_buff *skb, int cpu,
rps_lock(sd);
qlen = skb_queue_len(&sd->input_pkt_queue);
if (qlen <= netdev_max_backlog && !skb_flow_limit(skb, qlen)) {
- if (skb_queue_len(&sd->input_pkt_queue)) {
+ if (qlen) {
enqueue:
__skb_queue_tail(&sd->input_pkt_queue, skb);
input_queue_tail_incr_save(sd, qtail);
--
2.1.0
^ permalink raw reply related
* RE: [patch iproute2 1/6] iproute2: ipa: show switch id
From: David Laight @ 2014-12-05 9:54 UTC (permalink / raw)
To: 'Eric W. Biederman', Jiri Pirko
Cc: netdev@vger.kernel.org, davem@davemloft.net,
nhorman@tuxdriver.com, andy@greyhouse.net, tgraf@suug.ch,
dborkman@redhat.com, ogerlitz@mellanox.com, jesse@nicira.com,
pshelar@nicira.com, azhou@nicira.com, ben@decadent.org.uk,
stephen@networkplumber.org, jeffrey.t.kirsher@intel.com,
vyasevic@redhat.com, xiyou.wangcong@gmail.com,
john.r.fastabend@intel.com, edumazet@google.com, jhs@mojatatu.com,
sfeldma@gmail.com
In-Reply-To: <87388vw2xg.fsf@x220.int.ebiederm.org>
From: Eric W. Biederman
> Jiri Pirko <jiri@resnulli.us> writes:
>
> > Thu, Dec 04, 2014 at 09:06:14PM CET, ebiederm@xmission.com wrote:
> >>ebiederm@xmission.com (Eric W. Biederman) writes:
> >>
> >>> Jiri Pirko <jiri@resnulli.us> writes:
> >>>
> >>>>>So this id needs to be globally unique?
> >>>>
> >>>> No. It is enough to be unique within a single system. It serves for no
> >>>> more than to find out 2 ids are same or not, no other info value.
> >>>>
> >>>> So when the drivers uses sane ids (like mac for example, or in case of
> >>>> rocker an id which is passed by qemu command line), the chances of
> >>>> collision are very very close to none (never say never).
> >>
> >>Thinking about what you said a little more.
> >>
> >>Two different sources of persistent numbers picking numbers by
> >>completely different algorithms can give you no assurance that you don't
> >>produce conflicts.
> >>
> >>The switch id as desisgned can not work.
> >>
> >>There are expected to be between 2**36 to 2**40 devices in this world.
> >>Your first switch id is a 64it number. At the very best by the birthday
> >>pardox predicts there will be a conflict ever 2**32 devices or between
> >>2**4 and 2**8 devices in the world with conflicts. If the ids are not
> >>randomly distributed (which they won't be) things could easily be much
> >>much worse.
> >>
> >>That is just good enough the code could get out there and run for years
> >>before you have the nightmare of having to fix all of userspace. That
> >>is a nightmare no one needs.
> >>
> >>So please remove this broken code, and this broken concept from the
> >>kernel and go back to the drawing board.
> >
> > In that case the phys port id is broken in the same way. Let's rather
> > think about how to avoid conflicts for both. Given the fact the
> > conflicts should be avoided only on a single baremetal, that should be
> > doable (for (bad) example using driver name mixed with driver created
> > id).
>
> No. phys_port_id is not broken in the same way, and phys_port_id does
> not have the same set of properties.
>
> phys_port_id's in practice all have an IEEE prefix that identifies the
> manufacturer and a manufacture assigned serial number. Aka a mac
> address or a EUID-64. What the mlx4 ethernet driver is doing retunring
> a 64bit EUID-64 I don't know. If there are problems in the worst
> case issues with phys_port_id are fixable by simple driver tweaks,
> because fundamentally we are working with globally uniuqe identifiers.
> Well globally unique baring manufacturing bugs in eeproms.
Manufacturers have to generate unique MAC addresses - otherwise people complain.
But can't be assumed to put different 'serial numbers' in other devices.
If you look at USB memory sticks you are likely to find that the serial
number in the (equivalent of the) ATA identify response isn't unique.
So I doubt you can use the value to distinguish between devices.
You also get the situation where ethernet MAC addresses only have to be
unique within a collision domain. Many old sun systems used a single MAC
address - valid because they assumed/required that multiple interfaces
be connected to different networks.
So even MAC addresses aren't per-interface.
David
^ permalink raw reply
* Re: 3.12.33 - BUG xfrm_selector_match+0x25/0x2f6
From: Julian Anastasov @ 2014-12-05 9:55 UTC (permalink / raw)
To: Smart Weblications GmbH - Florian Wiessner
Cc: Steffen Klassert, netdev, LKML, stable, Simon Horman, lvs-devel
In-Reply-To: <5481173A.9060308@smart-weblications.de>
Hello,
Adding Simon to CC...
On Fri, 5 Dec 2014, Smart Weblications GmbH - Florian Wiessner wrote:
> i tried with 3.12.33 without any XFRM and now got this one (which is reproducable):
>
> [ 233.956012] BUG: unable to handle kernel NULL pointer dereference at 00000000
> 00000014
> [ 233.956218] IP: [<ffffffffa013a470>] nf_ct_seqadj_set+0x60/0x90 [nf_conntrack
It seems fix from 3.13 was not sent to 3.12 stable:
commit b25adce1606427fd8 ("ipvs: correct usage/allocation of seqadj ext in
ipvs")
There was related change but it is not needed
for stable kernels:
commit db12cf27435356017e ("netfilter: WARN about wrong usage of sequence
number adjustments"
Simon, can we try commit b25adce1606427fd8 for 3.12?
> setup is like this:
>
>
> #virtual=<myVIP>:21
> # real=10.10.1.20:21 masq
> # real=10.10.1.21:21 masq
> # real=10.10.1.22:21 masq
> # real=10.10.1.23:21 masq
> # persistent=600
> # service=ftp
> # scheduler=rr
> # protocol=tcp
> # checktype=connect
>
> ( i remarked it to prevent fruther crashes...)
>
> when ip_vs_ftp is loaded and someone trying to make a ftp connection, the system
> panics instantly.
>
> 10.10.1.20 - 10.10.1.23 are lxc-containers using veth connected to the bridge
> running on 4 different nodes. The node running ldirector/ipvsadm has also one of
> those containers running (don't know if that matters)
It is always good to know the setup. Do you access VIP
from local clients (from director)?
> brctl show
> bridge name bridge id STP enabled interfaces
> br0 8000.00259052bbf4 no bond0
> vethMKELUc
> vethXdWGqf
> vethgJMmEb
> vethmKNqFc
>
>
> I disabled the ftp server lxc container on the node doing ip_vs, so that the
> endpoint of the connection is not on the same node and tried again but with the
> same result.
>
> Unfortunatelly i cannot test with newer kernels than 3.12, because ocfs2 is
> somehow broken in >= 3.14
Before I create patch to avoid rerouting for
LOCAL_IN you can try to set IPVS sysctl var "snat_reroute" to 0
or even to change ip_vs_route_me_harder() function just to return 0.
snat_reroute=1 (a default value) is needed if you have
multiple links to clients and use ip rules to select
correct route by src ip (after SNAT). If you have single
uplink snat_reroute can be 0.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* RE: [patch net-next v2 1/2] rocker: introduce be put/get variants and use it when appropriate
From: David Laight @ 2014-12-05 9:57 UTC (permalink / raw)
To: 'Scott Feldman', Jiri Pirko; +Cc: Netdev, David S. Miller
In-Reply-To: <CAE4R7bAgSji_rt3147Kt8jqyT5_yqBCbKjSLgZVa8xkRc0dndA@mail.gmail.com>
From: Scott Feldman
> Signed-off-by: Scott Feldman <sfeldma@gmail.com>
>
> On Wed, Dec 3, 2014 at 5:14 AM, Jiri Pirko <jiri@resnulli.us> wrote:
> > This kills the sparse warnings.
> >
> > Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> > ---
> > v1->v2:
> > -no change
> > ---
> > drivers/net/ethernet/rocker/rocker.c | 79 ++++++++++++++++++++++--------------
> > 1 file changed, 48 insertions(+), 31 deletions(-)
> >
> > diff --git a/drivers/net/ethernet/rocker/rocker.c b/drivers/net/ethernet/rocker/rocker.c
> > index fded127..4b060fb 100644
> > --- a/drivers/net/ethernet/rocker/rocker.c
> > +++ b/drivers/net/ethernet/rocker/rocker.c
> > @@ -648,6 +648,11 @@ static u16 rocker_tlv_get_u16(const struct rocker_tlv *tlv)
> > return *(u16 *) rocker_tlv_data(tlv);
> > }
> >
> > +static __be16 rocker_tlv_get_be16(const struct rocker_tlv *tlv)
> > +{
> > + return *(__be16 *) rocker_tlv_data(tlv);
> > +}
*(int_type *)foo always rings alarm bells.....
That looks dubious on systems where misaligned transfers fault.
David
^ permalink raw reply
* Re: Is this 32-bit NCM?y
From: Enrico Mioso @ 2014-12-05 9:59 UTC (permalink / raw)
To: Bjørn Mork
Cc: Kevin Zhu, Midge Shaojun Tan, Eli Britstein, Alex Strizhevsky,
youtux-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org,
linux-usb-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <8761dqjuuh.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
Yes Bjorn: I should say that's true.
and - in general, touching the device driver to make it flexible is surely
important, especially to make it more easy to fix / "expand" in the future.
I was referring to modifying the huawei_cdc_ncm.c driver only for specific
huawei workarounds / firmware misbehaviours.
thank to everyone,
Enrico
--
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: am335x: cpsw: interrupt failure
From: Yegor Yefremov @ 2014-12-05 10:03 UTC (permalink / raw)
To: Felipe Balbi; +Cc: netdev, N, Mugunthan V
In-Reply-To: <20141204165609.GJ18045@saruman>
[-- Attachment #1: Type: text/plain, Size: 2645 bytes --]
On Thu, Dec 4, 2014 at 5:56 PM, Felipe Balbi <balbi@ti.com> wrote:
> Hi,
>
> On Thu, Dec 04, 2014 at 05:41:38PM +0100, Yegor Yefremov wrote:
>> I have following problem. My systems reboots at high network load
>> after this commit (found via git bissect):
>>
>> commit 55601c9f24670ba926ebdd4d712ac3b177232330
>> Author: Felipe Balbi <balbi@ti.com>
>> Date: Mon Sep 8 17:54:58 2014 -0700
>>
>> arm: omap: intc: switch over to linear irq domain
>>
>> now that we don't need to support legacy board-files,
>> we can completely switch over to a linear irq domain
>> and make use of irq_alloc_domain_generic_chips() to
>> allocate all generic irq chips for us.
>>
>> Signed-off-by: Felipe Balbi <balbi@ti.com>
>> Signed-off-by: Tony Lindgren <tony@atomide.com>
>>
>> and I get following error messages:
>>
>> irq 0, desc: cf004000, depth: 1, count: 0, unhandled: 0
>
> irq 0 ? Weird, that's not a valid IRQ.
>
>> ->handle_irq(): c0087fc0, handle_bad_irq+0x0/0x258
>> ->irq_data.chip(): c08e7174, no_irq_chip+0x0/0x68
>> ->action(): (null)
>> IRQ_NOPROBE set
>> IRQ_NOREQUEST set
>> irq 0, desc: cf004000, depth: 1, count: 0, unhandled: 0
>> ->handle_irq(): c0087fc0, handle_bad_irq+0x0/0x258
>> ->irq_data.chip(): c08e7174, no_irq_chip+0x0/0x68
>> ->action(): (null)
>> IRQ_NOPROBE set
>> IRQ_NOREQUEST set
>> irq 0, desc: cf004000, depth: 1, count: 0, unhandled: 0
>> ->handle_irq(): c0087fc0, handle_bad_irq+0x0/0x258
>> ->irq_data.chip(): c08e7174, no_irq_chip+0x0/0x68
>> ->action(): (null)
>> IRQ_NOPROBE set
>> IRQ_NOREQUEST set
>> irq 0, desc: cf004000, depth: 1, count: 0, unhandled: 0
>> ->handle_irq(): c0087fc0, handle_bad_irq+0x0/0x258
>> ->irq_data.chip(): c08e7174, no_irq_chip+0x0/0x68
>> ->action(): (null)
>>
>> My system: am335x with fast ethernet on the first slave and gigabit
>> Ethernet on second CPSW slave. This issue occurs, when I ran nuttcp
>> with default settings.
>>
>> With commit above I can at least see these messages, but 3.18-rc7 for
>> example reboots without any messages.
>>
>> Any idea?
>
> if you take v3.18-rc7 and just revert that commit, does the problem go
> away ?
git revert failed as the driver has more changes meanwhile or I'm
missing some params. I've tried to force the driver to use legacy
routines, but then I don't get pass U-Boot's "Starting kernel ..." See
attached patch.
Compiler used:
Linux version 3.18.0-rc7 (...) (gcc version 4.8.3 20140320
(prerelease) (Sourcery CodeBench Lite 2014.05-29) ) #309 SMP Fri Dec 5
10:59:38 CET 2014
Btw, what am335x based hardware do you have? I can run tests on both
BBB and am335x-evmsk.
Yegor
[-- Attachment #2: 0001-Irq-patch-revert.patch --]
[-- Type: application/octet-stream, Size: 2338 bytes --]
From 889a0588e884083399e644909ec39e834f37c4d3 Mon Sep 17 00:00:00 2001
From: Yegor Yefremov <yegorslists@googlemail.com>
Date: Fri, 5 Dec 2014 10:54:37 +0100
Subject: [PATCH] Irq patch revert
---
drivers/irqchip/irq-omap-intc.c | 21 +++++++++++++++------
1 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/drivers/irqchip/irq-omap-intc.c b/drivers/irqchip/irq-omap-intc.c
index 28718d3..a60a0ac 100644
--- a/drivers/irqchip/irq-omap-intc.c
+++ b/drivers/irqchip/irq-omap-intc.c
@@ -186,6 +186,7 @@ void omap3_intc_suspend(void)
omap_ack_irq(NULL);
}
+#if 0
static int __init omap_alloc_gc_of(struct irq_domain *d, void __iomem *base)
{
int ret;
@@ -222,7 +223,7 @@ static int __init omap_alloc_gc_of(struct irq_domain *d, void __iomem *base)
return 0;
}
-
+#endif
static void __init omap_alloc_gc_legacy(void __iomem *base,
unsigned int irq_start, unsigned int num)
{
@@ -243,6 +244,7 @@ static void __init omap_alloc_gc_legacy(void __iomem *base,
IRQ_NOREQUEST | IRQ_NOPROBE, 0);
}
+#if 0
static int __init omap_init_irq_of(struct device_node *node)
{
int ret;
@@ -262,6 +264,7 @@ static int __init omap_init_irq_of(struct device_node *node)
return ret;
}
+#endif
static int __init omap_init_irq_legacy(u32 base)
{
@@ -301,13 +304,13 @@ static int __init omap_init_irq(u32 base, struct device_node *node)
{
int ret;
- if (node)
+ /*if (node)
ret = omap_init_irq_of(node);
- else
+ else*/
ret = omap_init_irq_legacy(base);
- if (ret == 0)
- omap_irq_enable_protection();
+ /*if (ret == 0)
+ omap_irq_enable_protection();*/
return ret;
}
@@ -376,6 +379,7 @@ static int __init intc_of_init(struct device_node *node,
struct device_node *parent)
{
int ret;
+ struct resource res;
omap_nr_pending = 3;
omap_nr_irqs = 96;
@@ -383,12 +387,17 @@ static int __init intc_of_init(struct device_node *node,
if (WARN_ON(!node))
return -ENODEV;
+ if (of_address_to_resource(node, 0, &res)) {
+ WARN(1, "unable to get intc registers\n");
+ return -EINVAL;
+ }
+
if (of_device_is_compatible(node, "ti,am33xx-intc")) {
omap_nr_irqs = 128;
omap_nr_pending = 4;
}
- ret = omap_init_irq(-1, of_node_get(node));
+ ret = omap_init_irq(res.start, of_node_get(node));
if (ret < 0)
return ret;
--
1.7.7
^ permalink raw reply related
* [PATCH] broadcom: Add BCM54616S phy support
From: Alessio Igor Bogani @ 2014-12-05 9:16 UTC (permalink / raw)
To: Florian Fainelli; +Cc: netdev, Alessio Igor Bogani
Signed-off-by: Alessio Igor Bogani <alessio.bogani@elettra.eu>
---
drivers/net/phy/Kconfig | 4 ++--
drivers/net/phy/broadcom.c | 14 ++++++++++++++
include/linux/brcmphy.h | 1 +
3 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/net/phy/Kconfig b/drivers/net/phy/Kconfig
index 75472cf7..eb35dcb 100644
--- a/drivers/net/phy/Kconfig
+++ b/drivers/net/phy/Kconfig
@@ -68,8 +68,8 @@ config SMSC_PHY
config BROADCOM_PHY
tristate "Drivers for Broadcom PHYs"
---help---
- Currently supports the BCM5411, BCM5421, BCM5461, BCM5464, BCM5481
- and BCM5482 PHYs.
+ Currently supports the BCM5411, BCM5421, BCM5461, BCM54616S, BCM5464,
+ BCM5481 and BCM5482 PHYs.
config BCM63XX_PHY
tristate "Drivers for Broadcom 63xx SOCs internal PHY"
diff --git a/drivers/net/phy/broadcom.c b/drivers/net/phy/broadcom.c
index 854f2c9..74cbf45 100644
--- a/drivers/net/phy/broadcom.c
+++ b/drivers/net/phy/broadcom.c
@@ -549,6 +549,19 @@ static struct phy_driver broadcom_drivers[] = {
.config_intr = bcm54xx_config_intr,
.driver = { .owner = THIS_MODULE },
}, {
+ .phy_id = PHY_ID_BCM54616S,
+ .phy_id_mask = 0xfffffff0,
+ .name = "Broadcom BCM54616S",
+ .features = PHY_GBIT_FEATURES |
+ SUPPORTED_Pause | SUPPORTED_Asym_Pause,
+ .flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
+ .config_init = bcm54xx_config_init,
+ .config_aneg = genphy_config_aneg,
+ .read_status = genphy_read_status,
+ .ack_interrupt = bcm54xx_ack_interrupt,
+ .config_intr = bcm54xx_config_intr,
+ .driver = { .owner = THIS_MODULE },
+}, {
.phy_id = PHY_ID_BCM5464,
.phy_id_mask = 0xfffffff0,
.name = "Broadcom BCM5464",
@@ -673,6 +686,7 @@ static struct mdio_device_id __maybe_unused broadcom_tbl[] = {
{ PHY_ID_BCM5411, 0xfffffff0 },
{ PHY_ID_BCM5421, 0xfffffff0 },
{ PHY_ID_BCM5461, 0xfffffff0 },
+ { PHY_ID_BCM54616S, 0xfffffff0 },
{ PHY_ID_BCM5464, 0xfffffff0 },
{ PHY_ID_BCM5482, 0xfffffff0 },
{ PHY_ID_BCM5482, 0xfffffff0 },
diff --git a/include/linux/brcmphy.h b/include/linux/brcmphy.h
index 7ccd928..1c9920b 100644
--- a/include/linux/brcmphy.h
+++ b/include/linux/brcmphy.h
@@ -11,6 +11,7 @@
#define PHY_ID_BCM5421 0x002060e0
#define PHY_ID_BCM5464 0x002060b0
#define PHY_ID_BCM5461 0x002060c0
+#define PHY_ID_BCM54616S 0x03625d10
#define PHY_ID_BCM57780 0x03625d90
#define PHY_ID_BCM7250 0xae025280
--
2.1.3
^ permalink raw reply related
* Re: [patch net-next v2 1/2] rocker: introduce be put/get variants and use it when appropriate
From: Jiri Pirko @ 2014-12-05 10:25 UTC (permalink / raw)
To: David Laight; +Cc: 'Scott Feldman', Netdev, David S. Miller
In-Reply-To: <063D6719AE5E284EB5DD2968C1650D6D1CA033CC@AcuExch.aculab.com>
Fri, Dec 05, 2014 at 10:57:43AM CET, David.Laight@ACULAB.COM wrote:
>From: Scott Feldman
>> Signed-off-by: Scott Feldman <sfeldma@gmail.com>
>>
>> On Wed, Dec 3, 2014 at 5:14 AM, Jiri Pirko <jiri@resnulli.us> wrote:
>> > This kills the sparse warnings.
>> >
>> > Signed-off-by: Jiri Pirko <jiri@resnulli.us>
>> > ---
>> > v1->v2:
>> > -no change
>> > ---
>> > drivers/net/ethernet/rocker/rocker.c | 79 ++++++++++++++++++++++--------------
>> > 1 file changed, 48 insertions(+), 31 deletions(-)
>> >
>> > diff --git a/drivers/net/ethernet/rocker/rocker.c b/drivers/net/ethernet/rocker/rocker.c
>> > index fded127..4b060fb 100644
>> > --- a/drivers/net/ethernet/rocker/rocker.c
>> > +++ b/drivers/net/ethernet/rocker/rocker.c
>> > @@ -648,6 +648,11 @@ static u16 rocker_tlv_get_u16(const struct rocker_tlv *tlv)
>> > return *(u16 *) rocker_tlv_data(tlv);
>> > }
>> >
>> > +static __be16 rocker_tlv_get_be16(const struct rocker_tlv *tlv)
>> > +{
>> > + return *(__be16 *) rocker_tlv_data(tlv);
>> > +}
>
>*(int_type *)foo always rings alarm bells.....
>
>That looks dubious on systems where misaligned transfers fault.
This is common use:
for example nla_get_be16
but when you grep kernel, you see many more.
Also, rocker has all accesses like these aligned.
>
> David
>
^ permalink raw reply
* [PATCH 0/2] DMA API usage fixes in gianfar
From: Arseny Solokha @ 2014-12-05 10:37 UTC (permalink / raw)
To: Claudiu Manoil; +Cc: netdev, linux-kernel, Arseny Solokha
Hello.
This patch set fixes DMA API usage issues in gianfar ethernet driver
reported by the kernel w/ DMA API debug enabled.
There were even reports that the kernel sometimes oopsed in the past
because of kernel paging request handling failures, though it was likely
observed on some ancient versions. And while I personally doesn't have
any strong evidence of this, there's no reason to let these possible
failures live any longer.
Arseny Solokha (2):
gianfar: handle map error in gfar_new_rxbdp()
gianfar: handle map error in gfar_start_xmit()
drivers/net/ethernet/freescale/gianfar.c | 49 ++++++++++++++++++++++++++------
1 file changed, 41 insertions(+), 8 deletions(-)
--
Regards,
Arseny Solokha.
^ 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