* Re: [PATCH 1/5] omap: panda: wlan board muxing
From: panduranga @ 2011-02-14 8:01 UTC (permalink / raw)
To: Ohad Ben-Cohen, Mallireddy, Panduranga
Cc: Coelho, Luciano, netdev, linux-omap, linux-mmc, Gabay, Benzy,
Gurumath, Pradeep, Mahaveer, Vishal, Boudet, Xavier, Jain, Naveen,
Savoy, Pavan, Halli, Manjunatha, tony, cjb
In-Reply-To: <AANLkTik4+CRp8B8Ajnpy-_k1m+=MZNe62c2WG8cjaz-D@mail.gmail.com>
Hi Ohad,
I will modify the patch accordingly.
Regards,
Pandu.
----- Original Message -----
From: "Ohad Ben-Cohen" <ohad@wizery.com>
To: "Mallireddy, Panduranga" <panduranga_mallireddy@ti.com>
Cc: "Coelho, Luciano" <coelho@ti.com>; <netdev@vger.kernel.org>;
<linux-omap@vger.kernel.org>; <linux-mmc@vger.kernel.org>; "Gabay, Benzy"
<benzyg@ti.com>; "Gurumath, Pradeep" <pradeepgurumath@ti.com>; "Mahaveer,
Vishal" <vishalm@ti.com>; "Boudet, Xavier" <x-boudet@ti.com>; "Jain, Naveen"
<naveen_jain@ti.com>; "Savoy, Pavan" <pavan_savoy@ti.com>; "Halli,
Manjunatha" <manjunatha_halli@ti.com>; <tony@atomide.com>; <cjb@laptop.org>
Sent: Monday, February 14, 2011 12:54 PM
Subject: Re: [PATCH 1/5] omap: panda: wlan board muxing
Hi Pandu,
On Mon, Feb 14, 2011 at 9:19 AM, <panduranga_mallireddy@ti.com> wrote:
> + /* WLAN IRQ - GPIO 53 */
> + OMAP4_MUX(GPMC_NCS3, OMAP_MUX_MODE3 | OMAP_PIN_INPUT_PULLUP),
Actually we don't need to pull up the IRQ line - it is always held by
the 1271 device, and there's no need for the host to pull it up
(wasting some power while doing it).
We have that on the ZOOM, but that's not necessary, and will be fixed
there, too.
Thanks,
Ohad.
^ permalink raw reply
* Re: [PATCH 02/14] net/fec: release mem_region requested in probe in error path and remove
From: Uwe Kleine-König @ 2011-02-14 8:25 UTC (permalink / raw)
To: David Miller; +Cc: netdev, shawn.guo, kernel
In-Reply-To: <20110213.131531.57465973.davem@davemloft.net>
Hi David,
On Sun, Feb 13, 2011 at 01:15:31PM -0800, David Miller wrote:
> From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> Date: Sun, 13 Feb 2011 22:07:09 +0100
> > On Fri, Feb 11, 2011 at 09:25:32PM -0800, David Miller wrote:
> >> I can't pull from that tree because it is _NOT_ based upon net-next-2.6
> >> and therefore brings in all kinds of commits not related to your work.
> > Sorry, I'm not used to the customs on netdev. I can rebase, but still I
> > wonder about the reason you cannot pull for. The only reason I can
> > imagine is that you fear unrelated breakage when taking these patches
> > that are already in Linus' tree. But if it's that, wouldn't it be great
> > the realize this breakage already now and not only during the next merge
> > window?
>
> My trees only merge in Linus's tree when absolutely necessary,
> to resolve conflicts or similar.
You don't merge Linus' tree, you merge mine that just happen to be based
on a newer version of Linus' tree. I'm sure Linus won't yell on you for
that. He only objects to merge directly from his tree, because the
result for him is an "empty" merge.
> We don't bring in unrelated changes into my tree, just for the
> sake of doing so.
>
> Otherwise Linus gets all of these ugly merge commits when he
> pulls from me, which are entirely unnecessary.
The result Linus gets if you pull my tree based on
v2.6.38-rc4-106-gd247852 (as it is now) is the same as if it were based
on v2.6.38-rc2-210-gc69b909 (which is the most recent commit net-next
currently bases on): my 14 patches and your merge commit. The reason for
that is that Linus already has the commits between
v2.6.38-rc2-210-gc69b909 and v2.6.38-rc4-106-gd247852. So this is really
only about when these commits enter *your* tree.
There are currently the following commits in Linus' tree that are used
by commits in net-next as parents:
c56eb8fb6dccb83d9fe62fd4dc00c834de9bc470
ff76015f3bdfbc482c723cb4f2559cef84d178ca (*)
c753796769e4fb0cd813b6e5801b3c01f4681d4f
0c21e3aaf6ae85bee804a325aa29c325209180fd (*)
e92427b289d252cfbd4cb5282d92f4ce1a5bb1fb (*)
1bae4ce27c9c90344f23c65ea6966c50ffeae2f5
7cc2edb83447775a34ed3bf9d29d8295a434b523 (*)
8f2771f2b85aea4d0f9a0137ad3b63d1173c0962 (*)
c4c93106741bbf61ecd05a2a835af8e3bf31c1bd (*)
c7c1806098752c1f46943d8db2c69aff07f5d4bc (*)
479600777bb588724d044815415f7d708d06644b (*)
1e6d93e45b231b3ae87c01902ede2315aacfe976 (*)
9b00b4157f7b3265de291ac8979a5f1611ce64ab
c69b90920a36b88ab0d649963d81355d865eeb05 (*)
and you don't want to take d247852 to this list because it's newer than
all these? How did you decide to take the newest in the list above and
why was that OK?
And as a last point let me note, that from Linus' POV the commits marked
with an asterisk above go into net-next by an empty merge.
Can you please reping me if you still consider that I should rebase my
tree for you to be able to merge it?
Best regards and thanks
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH v2 09/13] can: pruss CAN driver.
From: Subhasish Ghosh @ 2011-02-14 8:45 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: Kurt Van Dijck, davinci-linux-open-source, linux-arm-kernel,
m-watkins, nsekhar, sachi, open list:CAN NETWORK DRIVERS,
open list:CAN NETWORK DRIVERS, open list
In-Reply-To: <4D58D854.5090503@grandegger.com>
That is correct, we receive only pre-programmed CAN ids and "all" or "range"
implementation is not there in the PRU firmware.
Will check the sysfs option and update.
--------------------------------------------------
From: "Wolfgang Grandegger" <wg@grandegger.com>
Sent: Monday, February 14, 2011 12:53 PM
To: "Subhasish Ghosh" <subhasish@mistralsolutions.com>
Cc: "Kurt Van Dijck" <kurt.van.dijck@eia.be>;
<davinci-linux-open-source@linux.davincidsp.com>;
<linux-arm-kernel@lists.infradead.org>; <m-watkins@ti.com>;
<nsekhar@ti.com>; <sachi@mistralsolutions.com>; "open list:CAN NETWORK
DRIVERS" <socketcan-core@lists.berlios.de>; "open list:CAN NETWORK DRIVERS"
<netdev@vger.kernel.org>; "open list" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 09/13] can: pruss CAN driver.
> On 02/14/2011 05:54 AM, Subhasish Ghosh wrote:
>> Hello,
>>
>> I had a discussion regarding this with Wolfgang:
>>
>> http://www.mail-archive.com/socketcan-users@lists.berlios.de/msg00324.html
>>
>> The problem here is that we must configure the mailbox ID's and this
>> support is not available in the socketCan sub-system.
>
> To understand you correctly. A mailbox (or message object) can *only*
> receive messages with the pre-programmed CAN id? Isn't there a chance to
> receive all or a range of CAN ids? That's a very unusual piece of
> hardware. Anyway, using kernel configuration parameters to define the
> CAN id's would be the less flexible method. The user will not have a
> chance to change them at run-time. Using SysFS files would already be
> much better.
>
> Wolfgang.
^ permalink raw reply
* Re: [patch net-next-2.6] net: make dev->master general
From: Nicolas de Pesloüan @ 2011-02-14 8:48 UTC (permalink / raw)
To: Jiri Pirko; +Cc: netdev, davem, shemminger, kaber, fubar, eric.dumazet
In-Reply-To: <20110212164836.GB12156@psychotron.redhat.com>
Le 12/02/2011 17:48, Jiri Pirko a écrit :
> dev->master is now tightly connected to bonding driver. This patch makes
> this pointer more general and ready to be used by others.
>
> - netdev_set_master() - bond specifics moved to new function
> netdev_set_bond_master()
> - introduced netif_is_bond_slave() to check if device is a bonding slave
>
> Signed-off-by: Jiri Pirko<jpirko@redhat.com>
Hi Jiri,
Even if DaveM already applied your patch, I'm not comfortable with it.
What is the rational behind it? Do you have anything in mind to use the now "more general" master
field of net_device?
Of course, I won't advocate for every fields having only a single possible usage, but, using master
for several different things might jeopardize our ability to share an interface between several
logical interface systems:
Due to the current usage of the rx_handler field in net_device, the code suggest that an interface
cannot be part of a bridge and of a macvlan at the same time. Even if bridge provide an hook for
ebtables to ignore an skb and allow other to get it, macvlan cannot be registered on the same lower
interface as a bridge, because rx_handler can only hold a single value.
By giving master a more general meaning, I think we might face a similar problem. It might disallow
an interface to be enslaved to bonding and part of another logical interface at the same time, if
such logical interface also use the master field.
It doesn't mean I don't support the general idea, but I would like to clearly understand the
possible unexpected impact: do we want to stop interfaces to be "enslaved" to several logical
interface at the same time?
> ---
> drivers/infiniband/hw/nes/nes.c | 3 +-
> drivers/infiniband/hw/nes/nes_cm.c | 2 +-
> drivers/net/bonding/bond_main.c | 10 +++---
> drivers/net/cxgb3/cxgb3_offload.c | 3 +-
> include/linux/netdevice.h | 7 +++++
> net/core/dev.c | 49 +++++++++++++++++++++++++++---------
> 6 files changed, 54 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/infiniband/hw/nes/nes.c b/drivers/infiniband/hw/nes/nes.c
> index 3b4ec32..3d7f366 100644
> --- a/drivers/infiniband/hw/nes/nes.c
> +++ b/drivers/infiniband/hw/nes/nes.c
> @@ -153,7 +153,8 @@ static int nes_inetaddr_event(struct notifier_block *notifier,
> nesdev, nesdev->netdev[0]->name);
> netdev = nesdev->netdev[0];
> nesvnic = netdev_priv(netdev);
> - is_bonded = (netdev->master == event_netdev);
> + is_bonded = netif_is_bond_slave(netdev)&&
> + (netdev->master == event_netdev);
> if ((netdev == event_netdev) || is_bonded) {
> if (nesvnic->rdma_enabled == 0) {
> nes_debug(NES_DBG_NETDEV, "Returning without processing event for %s since"
> diff --git a/drivers/infiniband/hw/nes/nes_cm.c b/drivers/infiniband/hw/nes/nes_cm.c
> index 009ec81..ec3aa11 100644
> --- a/drivers/infiniband/hw/nes/nes_cm.c
> +++ b/drivers/infiniband/hw/nes/nes_cm.c
> @@ -1118,7 +1118,7 @@ static int nes_addr_resolve_neigh(struct nes_vnic *nesvnic, u32 dst_ip, int arpi
> return rc;
> }
>
> - if (nesvnic->netdev->master)
> + if (netif_is_bond_slave(netdev))
> netdev = nesvnic->netdev->master;
> else
> netdev = nesvnic->netdev;
> diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
> index 1df9f0e..9f87787 100644
> --- a/drivers/net/bonding/bond_main.c
> +++ b/drivers/net/bonding/bond_main.c
> @@ -1594,9 +1594,9 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
> }
> }
>
> - res = netdev_set_master(slave_dev, bond_dev);
> + res = netdev_set_bond_master(slave_dev, bond_dev);
> if (res) {
> - pr_debug("Error %d calling netdev_set_master\n", res);
> + pr_debug("Error %d calling netdev_set_bond_master\n", res);
> goto err_restore_mac;
> }
> /* open the slave since the application closed it */
> @@ -1812,7 +1812,7 @@ err_close:
> dev_close(slave_dev);
>
> err_unset_master:
> - netdev_set_master(slave_dev, NULL);
> + netdev_set_bond_master(slave_dev, NULL);
>
> err_restore_mac:
> if (!bond->params.fail_over_mac) {
> @@ -1992,7 +1992,7 @@ int bond_release(struct net_device *bond_dev, struct net_device *slave_dev)
> netif_addr_unlock_bh(bond_dev);
> }
>
> - netdev_set_master(slave_dev, NULL);
> + netdev_set_bond_master(slave_dev, NULL);
>
> #ifdef CONFIG_NET_POLL_CONTROLLER
> read_lock_bh(&bond->lock);
> @@ -2114,7 +2114,7 @@ static int bond_release_all(struct net_device *bond_dev)
> netif_addr_unlock_bh(bond_dev);
> }
>
> - netdev_set_master(slave_dev, NULL);
> + netdev_set_bond_master(slave_dev, NULL);
>
> /* close slave before restoring its mac address */
> dev_close(slave_dev);
> diff --git a/drivers/net/cxgb3/cxgb3_offload.c b/drivers/net/cxgb3/cxgb3_offload.c
> index 7ea94b5..862804f 100644
> --- a/drivers/net/cxgb3/cxgb3_offload.c
> +++ b/drivers/net/cxgb3/cxgb3_offload.c
> @@ -186,9 +186,10 @@ static struct net_device *get_iff_from_mac(struct adapter *adapter,
> dev = NULL;
> if (grp)
> dev = vlan_group_get_device(grp, vlan);
> - } else
> + } else if (netif_is_bond_slave(dev)) {
> while (dev->master)
> dev = dev->master;
The while() here suggests that nesting bonding is possible. This is not true (even if not enforced
yet). And even if it was true, then you needed to use netif_is_bond_slave(dev) inside the while()
loop, to be consistent.
> + }
> return dev;
> }
> }
> diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
> index 5a5baea..5a42b10 100644
> --- a/include/linux/netdevice.h
> +++ b/include/linux/netdevice.h
> @@ -2377,6 +2377,8 @@ extern int netdev_max_backlog;
> extern int netdev_tstamp_prequeue;
> extern int weight_p;
> extern int netdev_set_master(struct net_device *dev, struct net_device *master);
> +extern int netdev_set_bond_master(struct net_device *dev,
> + struct net_device *master);
> extern int skb_checksum_help(struct sk_buff *skb);
> extern struct sk_buff *skb_gso_segment(struct sk_buff *skb, u32 features);
> #ifdef CONFIG_BUG
> @@ -2437,6 +2439,11 @@ static inline void netif_set_gso_max_size(struct net_device *dev,
> dev->gso_max_size = size;
> }
>
> +static inline int netif_is_bond_slave(struct net_device *dev)
> +{
> + return dev->flags& IFF_SLAVE&& dev->priv_flags& IFF_BONDING;
> +}
> +
Does this means you also consider IFF_SLAVE as a "more general" flag now? Wasn't IFF_SLAVE a
sufficient evidence of the interface being enslaved to a bonding interface, before?
> extern struct pernet_operations __net_initdata loopback_net_ops;
>
> static inline int dev_ethtool_get_settings(struct net_device *dev,
> diff --git a/net/core/dev.c b/net/core/dev.c
> index d874fd1..a413276 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -3146,7 +3146,6 @@ static int __netif_receive_skb(struct sk_buff *skb)
> struct packet_type *ptype, *pt_prev;
> rx_handler_func_t *rx_handler;
> struct net_device *orig_dev;
> - struct net_device *master;
> struct net_device *null_or_orig;
> struct net_device *orig_or_bond;
> int ret = NET_RX_DROP;
> @@ -3173,15 +3172,19 @@ static int __netif_receive_skb(struct sk_buff *skb)
> */
> null_or_orig = NULL;
> orig_dev = skb->dev;
> - master = ACCESS_ONCE(orig_dev->master);
> if (skb->deliver_no_wcard)
> null_or_orig = orig_dev;
> - else if (master) {
> - if (__skb_bond_should_drop(skb, master)) {
> - skb->deliver_no_wcard = 1;
> - null_or_orig = orig_dev; /* deliver only exact match */
> - } else
> - skb->dev = master;
> + else if (netif_is_bond_slave(orig_dev)) {
> + struct net_device *bond_master = ACCESS_ONCE(orig_dev->master);
> +
> + if (likely(bond_master)) {
> + if (__skb_bond_should_drop(skb, bond_master)) {
> + skb->deliver_no_wcard = 1;
> + /* deliver only exact match */
> + null_or_orig = orig_dev;
> + } else
> + skb->dev = bond_master;
> + }
I think we need an "else" here. If orig_dev->master is NULL, while netif_is_bond_slave(orig_dev) is
TRUE, we apparently face an unexpected situation and we should at least issue a warning.
> }
>
> __this_cpu_inc(softnet_data.processed);
> @@ -4346,15 +4349,14 @@ static int __init dev_proc_init(void)
>
>
> /**
> - * netdev_set_master - set up master/slave pair
> + * netdev_set_master - set up master pointer
> * @slave: slave device
> * @master: new master device
> *
> * Changes the master device of the slave. Pass %NULL to break the
> * bonding. The caller must hold the RTNL semaphore. On a failure
> * a negative errno code is returned. On success the reference counts
> - * are adjusted, %RTM_NEWLINK is sent to the routing socket and the
> - * function returns zero.
> + * are adjusted and the function returns zero.
> */
> int netdev_set_master(struct net_device *slave, struct net_device *master)
> {
> @@ -4374,6 +4376,29 @@ int netdev_set_master(struct net_device *slave, struct net_device *master)
> synchronize_net();
> dev_put(old);
> }
> + return 0;
> +}
> +EXPORT_SYMBOL(netdev_set_master);
> +
> +/**
> + * netdev_set_bond_master - set up bonding master/slave pair
> + * @slave: slave device
> + * @master: new master device
> + *
> + * Changes the master device of the slave. Pass %NULL to break the
> + * bonding. The caller must hold the RTNL semaphore. On a failure
> + * a negative errno code is returned. On success %RTM_NEWLINK is sent
> + * to the routing socket and the function returns zero.
> + */
> +int netdev_set_bond_master(struct net_device *slave, struct net_device *master)
> +{
> + int err;
> +
> + ASSERT_RTNL();
> +
> + err = netdev_set_master(slave, master);
> + if (err)
> + return err;
> if (master)
> slave->flags |= IFF_SLAVE;
> else
> @@ -4382,7 +4407,7 @@ int netdev_set_master(struct net_device *slave, struct net_device *master)
> rtmsg_ifinfo(RTM_NEWLINK, slave, IFF_SLAVE);
> return 0;
> }
> -EXPORT_SYMBOL(netdev_set_master);
> +EXPORT_SYMBOL(netdev_set_bond_master);
>
> static void dev_change_rx_flags(struct net_device *dev, int flags)
> {
^ permalink raw reply
* [PATCH] pch_gbe: Fix the MAC Address load issue.
From: Toshiharu Okada @ 2011-02-14 8:51 UTC (permalink / raw)
To: ML netdev, David S. Miller
Cc: Tomoya Morinaga, LKML, Wang, Qi, Wang, Yong Y, Andrew, Intel OTC,
Ewe, Kok Howg
With the specification of hardware,
the processing at the time of driver starting was modified.
This device write automatically the MAC address read from serial ROM
into a MAC Adress1A/1B register at the time of power on reset.
However, when stable clock is not supplied,
the writing of MAC Adress1A/1B register may not be completed.
In this case, it is necessary to load MAC address to MAC Address1A/1B register
by the MAC Address1 load register.
This patch always does the above processing,
in order not to be dependent on system environment.
Signed-off-by: Toshiharu Okada <toshiharu-linux@dsn.okisemi.com>
---
drivers/net/pch_gbe/pch_gbe.h | 2 +-
drivers/net/pch_gbe/pch_gbe_main.c | 7 +++++++
2 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/drivers/net/pch_gbe/pch_gbe.h b/drivers/net/pch_gbe/pch_gbe.h
index a0c26a9..e1e33c8 100644
--- a/drivers/net/pch_gbe/pch_gbe.h
+++ b/drivers/net/pch_gbe/pch_gbe.h
@@ -73,7 +73,7 @@ struct pch_gbe_regs {
struct pch_gbe_regs_mac_adr mac_adr[16];
u32 ADDR_MASK;
u32 MIIM;
- u32 reserve2;
+ u32 MAC_ADDR_LOAD;
u32 RGMII_ST;
u32 RGMII_CTRL;
u32 reserve3[3];
diff --git a/drivers/net/pch_gbe/pch_gbe_main.c b/drivers/net/pch_gbe/pch_gbe_main.c
index 8ec48ad..8bba091 100644
--- a/drivers/net/pch_gbe/pch_gbe_main.c
+++ b/drivers/net/pch_gbe/pch_gbe_main.c
@@ -89,6 +89,12 @@ static unsigned int copybreak __read_mostly = PCH_GBE_COPYBREAK_DEFAULT;
static int pch_gbe_mdio_read(struct net_device *netdev, int addr, int reg);
static void pch_gbe_mdio_write(struct net_device *netdev, int addr, int reg,
int data);
+
+inline void pch_gbe_mac_load_mac_addr(struct pch_gbe_hw *hw)
+{
+ iowrite32(0x01, &hw->reg->MAC_ADDR_LOAD);
+}
+
/**
* pch_gbe_mac_read_mac_addr - Read MAC address
* @hw: Pointer to the HW structure
@@ -2333,6 +2339,7 @@ static int pch_gbe_probe(struct pci_dev *pdev,
netdev->features = NETIF_F_HW_CSUM | NETIF_F_GRO;
pch_gbe_set_ethtool_ops(netdev);
+ pch_gbe_mac_load_mac_addr(&adapter->hw);
pch_gbe_mac_reset_hw(&adapter->hw);
/* setup the private structure */
--
1.6.2.5
^ permalink raw reply related
* Re: [patch net-next-2.6] net: make dev->master general
From: Jiri Pirko @ 2011-02-14 9:01 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: netdev, davem, shemminger, kaber, fubar, eric.dumazet
In-Reply-To: <4D58EC6C.7030005@gmail.com>
Mon, Feb 14, 2011 at 09:48:44AM CET, nicolas.2p.debian@gmail.com wrote:
>Le 12/02/2011 17:48, Jiri Pirko a écrit :
>>dev->master is now tightly connected to bonding driver. This patch makes
>>this pointer more general and ready to be used by others.
>>
>> - netdev_set_master() - bond specifics moved to new function
>> netdev_set_bond_master()
>> - introduced netif_is_bond_slave() to check if device is a bonding slave
>>
>>Signed-off-by: Jiri Pirko<jpirko@redhat.com>
>
>Hi Jiri,
>
>Even if DaveM already applied your patch, I'm not comfortable with it.
>
>What is the rational behind it? Do you have anything in mind to use
>the now "more general" master field of net_device?
>
>Of course, I won't advocate for every fields having only a single
>possible usage, but, using master for several different things might
>jeopardize our ability to share an interface between several logical
>interface systems:
>
>Due to the current usage of the rx_handler field in net_device, the
>code suggest that an interface cannot be part of a bridge and of a
>macvlan at the same time. Even if bridge provide an hook for ebtables
>to ignore an skb and allow other to get it, macvlan cannot be
>registered on the same lower interface as a bridge, because
>rx_handler can only hold a single value.
>
>By giving master a more general meaning, I think we might face a
>similar problem. It might disallow an interface to be enslaved to
>bonding and part of another logical interface at the same time, if
>such logical interface also use the master field.
That is true. I think that it makes no sense to have iface enslaved in
bond and bridge at the same time. Do you have a scenario where it makes
sense?
>
>It doesn't mean I don't support the general idea, but I would like to
>clearly understand the possible unexpected impact: do we want to stop
>interfaces to be "enslaved" to several logical interface at the same
>time?
>
>>---
>> drivers/infiniband/hw/nes/nes.c | 3 +-
>> drivers/infiniband/hw/nes/nes_cm.c | 2 +-
>> drivers/net/bonding/bond_main.c | 10 +++---
>> drivers/net/cxgb3/cxgb3_offload.c | 3 +-
>> include/linux/netdevice.h | 7 +++++
>> net/core/dev.c | 49 +++++++++++++++++++++++++++---------
>> 6 files changed, 54 insertions(+), 20 deletions(-)
>>
>>diff --git a/drivers/infiniband/hw/nes/nes.c b/drivers/infiniband/hw/nes/nes.c
>>index 3b4ec32..3d7f366 100644
>>--- a/drivers/infiniband/hw/nes/nes.c
>>+++ b/drivers/infiniband/hw/nes/nes.c
>>@@ -153,7 +153,8 @@ static int nes_inetaddr_event(struct notifier_block *notifier,
>> nesdev, nesdev->netdev[0]->name);
>> netdev = nesdev->netdev[0];
>> nesvnic = netdev_priv(netdev);
>>- is_bonded = (netdev->master == event_netdev);
>>+ is_bonded = netif_is_bond_slave(netdev)&&
>>+ (netdev->master == event_netdev);
>> if ((netdev == event_netdev) || is_bonded) {
>> if (nesvnic->rdma_enabled == 0) {
>> nes_debug(NES_DBG_NETDEV, "Returning without processing event for %s since"
>>diff --git a/drivers/infiniband/hw/nes/nes_cm.c b/drivers/infiniband/hw/nes/nes_cm.c
>>index 009ec81..ec3aa11 100644
>>--- a/drivers/infiniband/hw/nes/nes_cm.c
>>+++ b/drivers/infiniband/hw/nes/nes_cm.c
>>@@ -1118,7 +1118,7 @@ static int nes_addr_resolve_neigh(struct nes_vnic *nesvnic, u32 dst_ip, int arpi
>> return rc;
>> }
>>
>>- if (nesvnic->netdev->master)
>>+ if (netif_is_bond_slave(netdev))
>> netdev = nesvnic->netdev->master;
>> else
>> netdev = nesvnic->netdev;
>>diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
>>index 1df9f0e..9f87787 100644
>>--- a/drivers/net/bonding/bond_main.c
>>+++ b/drivers/net/bonding/bond_main.c
>>@@ -1594,9 +1594,9 @@ int bond_enslave(struct net_device *bond_dev, struct net_device *slave_dev)
>> }
>> }
>>
>>- res = netdev_set_master(slave_dev, bond_dev);
>>+ res = netdev_set_bond_master(slave_dev, bond_dev);
>> if (res) {
>>- pr_debug("Error %d calling netdev_set_master\n", res);
>>+ pr_debug("Error %d calling netdev_set_bond_master\n", res);
>> goto err_restore_mac;
>> }
>> /* open the slave since the application closed it */
>>@@ -1812,7 +1812,7 @@ err_close:
>> dev_close(slave_dev);
>>
>> err_unset_master:
>>- netdev_set_master(slave_dev, NULL);
>>+ netdev_set_bond_master(slave_dev, NULL);
>>
>> err_restore_mac:
>> if (!bond->params.fail_over_mac) {
>>@@ -1992,7 +1992,7 @@ int bond_release(struct net_device *bond_dev, struct net_device *slave_dev)
>> netif_addr_unlock_bh(bond_dev);
>> }
>>
>>- netdev_set_master(slave_dev, NULL);
>>+ netdev_set_bond_master(slave_dev, NULL);
>>
>> #ifdef CONFIG_NET_POLL_CONTROLLER
>> read_lock_bh(&bond->lock);
>>@@ -2114,7 +2114,7 @@ static int bond_release_all(struct net_device *bond_dev)
>> netif_addr_unlock_bh(bond_dev);
>> }
>>
>>- netdev_set_master(slave_dev, NULL);
>>+ netdev_set_bond_master(slave_dev, NULL);
>>
>> /* close slave before restoring its mac address */
>> dev_close(slave_dev);
>>diff --git a/drivers/net/cxgb3/cxgb3_offload.c b/drivers/net/cxgb3/cxgb3_offload.c
>>index 7ea94b5..862804f 100644
>>--- a/drivers/net/cxgb3/cxgb3_offload.c
>>+++ b/drivers/net/cxgb3/cxgb3_offload.c
>>@@ -186,9 +186,10 @@ static struct net_device *get_iff_from_mac(struct adapter *adapter,
>> dev = NULL;
>> if (grp)
>> dev = vlan_group_get_device(grp, vlan);
>>- } else
>>+ } else if (netif_is_bond_slave(dev)) {
>> while (dev->master)
>> dev = dev->master;
>
>The while() here suggests that nesting bonding is possible. This is
>not true (even if not enforced yet). And even if it was true, then
>you needed to use netif_is_bond_slave(dev) inside the while() loop,
>to be consistent.
>
>>+ }
>> return dev;
>> }
>> }
>>diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
>>index 5a5baea..5a42b10 100644
>>--- a/include/linux/netdevice.h
>>+++ b/include/linux/netdevice.h
>>@@ -2377,6 +2377,8 @@ extern int netdev_max_backlog;
>> extern int netdev_tstamp_prequeue;
>> extern int weight_p;
>> extern int netdev_set_master(struct net_device *dev, struct net_device *master);
>>+extern int netdev_set_bond_master(struct net_device *dev,
>>+ struct net_device *master);
>> extern int skb_checksum_help(struct sk_buff *skb);
>> extern struct sk_buff *skb_gso_segment(struct sk_buff *skb, u32 features);
>> #ifdef CONFIG_BUG
>>@@ -2437,6 +2439,11 @@ static inline void netif_set_gso_max_size(struct net_device *dev,
>> dev->gso_max_size = size;
>> }
>>
>>+static inline int netif_is_bond_slave(struct net_device *dev)
>>+{
>>+ return dev->flags& IFF_SLAVE&& dev->priv_flags& IFF_BONDING;
>>+}
>>+
>
>Does this means you also consider IFF_SLAVE as a "more general" flag
>now? Wasn't IFF_SLAVE a sufficient evidence of the interface being
>enslaved to a bonding interface, before?
>
>> extern struct pernet_operations __net_initdata loopback_net_ops;
>>
>> static inline int dev_ethtool_get_settings(struct net_device *dev,
>>diff --git a/net/core/dev.c b/net/core/dev.c
>>index d874fd1..a413276 100644
>>--- a/net/core/dev.c
>>+++ b/net/core/dev.c
>>@@ -3146,7 +3146,6 @@ static int __netif_receive_skb(struct sk_buff *skb)
>> struct packet_type *ptype, *pt_prev;
>> rx_handler_func_t *rx_handler;
>> struct net_device *orig_dev;
>>- struct net_device *master;
>> struct net_device *null_or_orig;
>> struct net_device *orig_or_bond;
>> int ret = NET_RX_DROP;
>>@@ -3173,15 +3172,19 @@ static int __netif_receive_skb(struct sk_buff *skb)
>> */
>> null_or_orig = NULL;
>> orig_dev = skb->dev;
>>- master = ACCESS_ONCE(orig_dev->master);
>> if (skb->deliver_no_wcard)
>> null_or_orig = orig_dev;
>>- else if (master) {
>>- if (__skb_bond_should_drop(skb, master)) {
>>- skb->deliver_no_wcard = 1;
>>- null_or_orig = orig_dev; /* deliver only exact match */
>>- } else
>>- skb->dev = master;
>>+ else if (netif_is_bond_slave(orig_dev)) {
>>+ struct net_device *bond_master = ACCESS_ONCE(orig_dev->master);
>>+
>>+ if (likely(bond_master)) {
>>+ if (__skb_bond_should_drop(skb, bond_master)) {
>>+ skb->deliver_no_wcard = 1;
>>+ /* deliver only exact match */
>>+ null_or_orig = orig_dev;
>>+ } else
>>+ skb->dev = bond_master;
>>+ }
>
>I think we need an "else" here. If orig_dev->master is NULL, while
>netif_is_bond_slave(orig_dev) is TRUE, we apparently face an
>unexpected situation and we should at least issue a warning.
>
>> }
>>
>> __this_cpu_inc(softnet_data.processed);
>>@@ -4346,15 +4349,14 @@ static int __init dev_proc_init(void)
>>
>>
>> /**
>>- * netdev_set_master - set up master/slave pair
>>+ * netdev_set_master - set up master pointer
>> * @slave: slave device
>> * @master: new master device
>> *
>> * Changes the master device of the slave. Pass %NULL to break the
>> * bonding. The caller must hold the RTNL semaphore. On a failure
>> * a negative errno code is returned. On success the reference counts
>>- * are adjusted, %RTM_NEWLINK is sent to the routing socket and the
>>- * function returns zero.
>>+ * are adjusted and the function returns zero.
>> */
>> int netdev_set_master(struct net_device *slave, struct net_device *master)
>> {
>>@@ -4374,6 +4376,29 @@ int netdev_set_master(struct net_device *slave, struct net_device *master)
>> synchronize_net();
>> dev_put(old);
>> }
>>+ return 0;
>>+}
>>+EXPORT_SYMBOL(netdev_set_master);
>>+
>>+/**
>>+ * netdev_set_bond_master - set up bonding master/slave pair
>>+ * @slave: slave device
>>+ * @master: new master device
>>+ *
>>+ * Changes the master device of the slave. Pass %NULL to break the
>>+ * bonding. The caller must hold the RTNL semaphore. On a failure
>>+ * a negative errno code is returned. On success %RTM_NEWLINK is sent
>>+ * to the routing socket and the function returns zero.
>>+ */
>>+int netdev_set_bond_master(struct net_device *slave, struct net_device *master)
>>+{
>>+ int err;
>>+
>>+ ASSERT_RTNL();
>>+
>>+ err = netdev_set_master(slave, master);
>>+ if (err)
>>+ return err;
>> if (master)
>> slave->flags |= IFF_SLAVE;
>> else
>>@@ -4382,7 +4407,7 @@ int netdev_set_master(struct net_device *slave, struct net_device *master)
>> rtmsg_ifinfo(RTM_NEWLINK, slave, IFF_SLAVE);
>> return 0;
>> }
>>-EXPORT_SYMBOL(netdev_set_master);
>>+EXPORT_SYMBOL(netdev_set_bond_master);
>>
>> static void dev_change_rx_flags(struct net_device *dev, int flags)
>> {
>
^ permalink raw reply
* Re: [PATCH v2 09/13] can: pruss CAN driver.
From: Wolfgang Grandegger @ 2011-02-14 9:28 UTC (permalink / raw)
To: Subhasish Ghosh
Cc: sachi-EvXpCiN+lbve9wHmmfpqLFaTQe2KTcn/,
davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/,
CAN NETWORK DRIVERS, nsekhar-l0cyMroinI0, open list,
CAN NETWORK DRIVERS, m-watkins-l0cyMroinI0,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1F33D30F9B2D47ECA80CEC807A6C0727@subhasishg>
Hi Subhasish,
On 02/14/2011 09:45 AM, Subhasish Ghosh wrote:
> That is correct, we receive only pre-programmed CAN ids and "all" or
> "range" implementation is not there in the PRU firmware.
I'm curious about that CAN hardware and firmware. I found a nice block
diagram in [PATCH 0/13]:
http://marc.info/?l=linux-arm-kernel&m=129743511311286&w=4
So, one PRU is used for TX and the second for RX. Who is providing the
firmware you are using? Wouldn't it be possible to provide a firmware
for RX using just one message object (mailbox) with some buffering or
fifo? That would fit much better the SocketCAN approach favoring Basic
CAN controllers (in contrast to Full CAN [1]). And such an
implementation seems even simpler too me requiring less PRU resources.
And how about RTR and Extended CAN IDs? Is that supported?
Thanks,
Wolfgang.
[1] http://www.kvaser.com/en/about-can/the-can-protocol/18.html
^ permalink raw reply
* Re: [PATCH v2 09/13] can: pruss CAN driver.
From: Marc Kleine-Budde @ 2011-02-14 9:35 UTC (permalink / raw)
To: Subhasish Ghosh
Cc: sachi-EvXpCiN+lbve9wHmmfpqLFaTQe2KTcn/,
davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/,
CAN NETWORK DRIVERS, nsekhar-l0cyMroinI0, open list,
CAN NETWORK DRIVERS, Wolfgang Grandegger, m-watkins-l0cyMroinI0,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1F33D30F9B2D47ECA80CEC807A6C0727@subhasishg>
[-- Attachment #1.1: Type: text/plain, Size: 613 bytes --]
Hello,
On 02/14/2011 09:45 AM, Subhasish Ghosh wrote:
> That is correct, we receive only pre-programmed CAN ids and "all" or
> "range" implementation is not there in the PRU firmware.
I'd really like to see that you add a "all" implementation to the
firmware. Or even better use the standard id/mask approach.
cheers, Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* [PATCH] bluethooth: sco: fix information leak to userspace
From: Vasiliy Kulikov @ 2011-02-14 10:54 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: security-DgEjT+Ai2ygdnm+yROfE0A, Marcel Holtmann,
Gustavo F. Padovan, David S. Miller,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
struct sco_conninfo has one padding byte in the end. Local variable
cinfo of type sco_conninfo is copied to userspace with this uninizialized
one byte, leading to old stack contents leak.
Signed-off-by: Vasiliy Kulikov <segoon-cxoSlKxDwOJWk0Htik3J/w@public.gmane.org>
---
Compile tested.
net/bluetooth/sco.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/bluetooth/sco.c b/net/bluetooth/sco.c
index 960c6d1..926ed39 100644
--- a/net/bluetooth/sco.c
+++ b/net/bluetooth/sco.c
@@ -703,6 +703,7 @@ static int sco_sock_getsockopt_old(struct socket *sock, int optname, char __user
break;
}
+ memset(&cinfo, 0, sizeof(cinfo));
cinfo.hci_handle = sco_pi(sk)->conn->hcon->handle;
memcpy(cinfo.dev_class, sco_pi(sk)->conn->hcon->dev_class, 3);
--
1.7.0.4
^ permalink raw reply related
* [PATCH] bluetooth: bnep: fix buffer overflow
From: Vasiliy Kulikov @ 2011-02-14 10:54 UTC (permalink / raw)
To: linux-kernel-u79uwXL29TY76Z2rM5mHXA
Cc: security-DgEjT+Ai2ygdnm+yROfE0A, Marcel Holtmann,
Gustavo F. Padovan, David S. Miller, Tejun Heo,
linux-bluetooth-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
Struct ca is copied from userspace. It is not checked whether the "device"
field is NULL terminated. This potentially leads to BUG() inside of
alloc_netdev_mqs() and/or information leak by creating a device with a name
made of contents of kernel stack.
Signed-off-by: Vasiliy Kulikov <segoon-cxoSlKxDwOJWk0Htik3J/w@public.gmane.org>
---
Compile tested.
net/bluetooth/bnep/sock.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/net/bluetooth/bnep/sock.c b/net/bluetooth/bnep/sock.c
index 2862f53..30faaf1 100644
--- a/net/bluetooth/bnep/sock.c
+++ b/net/bluetooth/bnep/sock.c
@@ -88,6 +88,7 @@ static int bnep_sock_ioctl(struct socket *sock, unsigned int cmd, unsigned long
sockfd_put(nsock);
return -EBADFD;
}
+ ca.device[sizeof(ca.device)-1] = 0;
err = bnep_add_connection(&ca, nsock);
if (!err) {
--
1.7.0.4
^ permalink raw reply related
* [PATCH] bridge: netfilter: fix information leak
From: Vasiliy Kulikov @ 2011-02-14 10:54 UTC (permalink / raw)
To: linux-kernel
Cc: security, Bart De Schuymer, Patrick McHardy, Stephen Hemminger,
David S. Miller, ebtables-user, ebtables-devel, netfilter-devel,
netfilter, coreteam, bridge, netdev
Struct tmp is copied from userspace. It is not checked whether the "name"
field is NULL terminated. This may lead to buffer overflow and passing
contents of kernel stack as a module name to try_then_request_module() and,
consequently, to modprobe commandline. It would be seen by all userspace
processes.
Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
---
Compile tested.
net/bridge/netfilter/ebtables.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/net/bridge/netfilter/ebtables.c b/net/bridge/netfilter/ebtables.c
index 5f1825d..1ea820b 100644
--- a/net/bridge/netfilter/ebtables.c
+++ b/net/bridge/netfilter/ebtables.c
@@ -1107,6 +1107,8 @@ static int do_replace(struct net *net, const void __user *user,
if (tmp.num_counters >= INT_MAX / sizeof(struct ebt_counter))
return -ENOMEM;
+ tmp.name[sizeof(tmp.name)-1] = 0;
+
countersize = COUNTER_OFFSET(tmp.nentries) * nr_cpu_ids;
newinfo = vmalloc(sizeof(*newinfo) + countersize);
if (!newinfo)
--
1.7.0.4
^ permalink raw reply related
* [PATCH] core: dev: don't call BUG() on bad input
From: Vasiliy Kulikov @ 2011-02-14 10:56 UTC (permalink / raw)
To: linux-kernel
Cc: David S. Miller, Eric Dumazet, Tom Herbert, Changli Gao,
Jesse Gross, netdev
alloc_netdev() may be called with too long name (more that IFNAMSIZ bytes).
Currently this leads to BUG(). Other insane inputs (bad txqs, rxqs) and
even OOM don't lead to BUG(). Made alloc_netdev() return NULL, like on
other errors.
Signed-off-by: Vasiliy Kulikov <segoon@openwall.com>
---
Compile tested.
net/core/dev.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 6392ea0..12ef4b0 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5761,7 +5761,10 @@ struct net_device *alloc_netdev_mqs(int sizeof_priv, const char *name,
size_t alloc_size;
struct net_device *p;
- BUG_ON(strlen(name) >= sizeof(dev->name));
+ if (strnlen(name, sizeof(dev->name)) >= sizeof(dev->name)) {
+ pr_err("alloc_netdev: Too long device name \n");
+ return NULL;
+ }
if (txqs < 1) {
pr_err("alloc_netdev: Unable to allocate device "
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/1] tproxy: do not assign timewait sockets to skb->sk
From: Florian Westphal @ 2011-02-14 11:44 UTC (permalink / raw)
To: netfilter-devel; +Cc: netdev, Balazs Scheidler, KOVACS Krisztian
Assigning a socket in timewait state to skb->sk can trigger
kernel oops, e.g. in nfnetlink_log, which does:
if (skb->sk) {
read_lock_bh(&skb->sk->sk_callback_lock);
if (skb->sk->sk_socket && skb->sk->sk_socket->file) ...
in the timewait case, accessing sk->sk_callback_lock and sk->sk_socket
is invalid.
Either all of these spots will need to add a test for sk->sk_state != TCP_TIME_WAIT,
or xt_TPROXY must not assign a timewait socket to skb->sk.
This does the latter.
If a TW socket is found, assign the tproxy nfmark, but skip the skb->sk assignment,
thus mimicking behaviour of a '-m socket .. -j MARK/ACCEPT' re-routing rule.
The 'SYN to TW socket' case is left unchanged -- we try to redirect to the
listener socket.
Cc: Balazs Scheidler <bazsi@balabit.hu>
Cc: KOVACS Krisztian <hidden@balabit.hu>
Signed-off-by: Florian Westphal <fwestphal@astaro.com>
---
include/net/netfilter/nf_tproxy_core.h | 12 +-----------
net/netfilter/nf_tproxy_core.c | 27 ++++++++++++---------------
net/netfilter/xt_TPROXY.c | 22 ++++++++++++++++++++--
net/netfilter/xt_socket.c | 13 +++++++++++--
4 files changed, 44 insertions(+), 30 deletions(-)
diff --git a/include/net/netfilter/nf_tproxy_core.h b/include/net/netfilter/nf_tproxy_core.h
index cd85b3b..e505358 100644
--- a/include/net/netfilter/nf_tproxy_core.h
+++ b/include/net/netfilter/nf_tproxy_core.h
@@ -201,18 +201,8 @@ nf_tproxy_get_sock_v6(struct net *net, const u8 protocol,
}
#endif
-static inline void
-nf_tproxy_put_sock(struct sock *sk)
-{
- /* TIME_WAIT inet sockets have to be handled differently */
- if ((sk->sk_protocol == IPPROTO_TCP) && (sk->sk_state == TCP_TIME_WAIT))
- inet_twsk_put(inet_twsk(sk));
- else
- sock_put(sk);
-}
-
/* assign a socket to the skb -- consumes sk */
-int
+void
nf_tproxy_assign_sock(struct sk_buff *skb, struct sock *sk);
#endif
diff --git a/net/netfilter/nf_tproxy_core.c b/net/netfilter/nf_tproxy_core.c
index 4d87bef..474d621 100644
--- a/net/netfilter/nf_tproxy_core.c
+++ b/net/netfilter/nf_tproxy_core.c
@@ -28,26 +28,23 @@ nf_tproxy_destructor(struct sk_buff *skb)
skb->destructor = NULL;
if (sk)
- nf_tproxy_put_sock(sk);
+ sock_put(sk);
}
/* consumes sk */
-int
+void
nf_tproxy_assign_sock(struct sk_buff *skb, struct sock *sk)
{
- bool transparent = (sk->sk_state == TCP_TIME_WAIT) ?
- inet_twsk(sk)->tw_transparent :
- inet_sk(sk)->transparent;
-
- if (transparent) {
- skb_orphan(skb);
- skb->sk = sk;
- skb->destructor = nf_tproxy_destructor;
- return 1;
- } else
- nf_tproxy_put_sock(sk);
-
- return 0;
+ /* assigning tw sockets complicates things; most
+ * skb->sk->X checks would have to test sk->sk_state first */
+ if (sk->sk_state == TCP_TIME_WAIT) {
+ inet_twsk_put(inet_twsk(sk));
+ return;
+ }
+
+ skb_orphan(skb);
+ skb->sk = sk;
+ skb->destructor = nf_tproxy_destructor;
}
EXPORT_SYMBOL_GPL(nf_tproxy_assign_sock);
diff --git a/net/netfilter/xt_TPROXY.c b/net/netfilter/xt_TPROXY.c
index 640678f..dcfd57e 100644
--- a/net/netfilter/xt_TPROXY.c
+++ b/net/netfilter/xt_TPROXY.c
@@ -33,6 +33,20 @@
#include <net/netfilter/nf_tproxy_core.h>
#include <linux/netfilter/xt_TPROXY.h>
+static bool tproxy_sk_is_transparent(struct sock *sk)
+{
+ if (sk->sk_state != TCP_TIME_WAIT) {
+ if (inet_sk(sk)->transparent)
+ return true;
+ sock_put(sk);
+ } else {
+ if (inet_twsk(sk)->tw_transparent)
+ return true;
+ inet_twsk_put(inet_twsk(sk));
+ }
+ return false;
+}
+
static inline __be32
tproxy_laddr4(struct sk_buff *skb, __be32 user_laddr, __be32 daddr)
{
@@ -141,7 +155,7 @@ tproxy_tg4(struct sk_buff *skb, __be32 laddr, __be16 lport,
skb->dev, NFT_LOOKUP_LISTENER);
/* NOTE: assign_sock consumes our sk reference */
- if (sk && nf_tproxy_assign_sock(skb, sk)) {
+ if (sk && tproxy_sk_is_transparent(sk)) {
/* This should be in a separate target, but we don't do multiple
targets on the same rule yet */
skb->mark = (skb->mark & ~mark_mask) ^ mark_value;
@@ -149,6 +163,8 @@ tproxy_tg4(struct sk_buff *skb, __be32 laddr, __be16 lport,
pr_debug("redirecting: proto %hhu %pI4:%hu -> %pI4:%hu, mark: %x\n",
iph->protocol, &iph->daddr, ntohs(hp->dest),
&laddr, ntohs(lport), skb->mark);
+
+ nf_tproxy_assign_sock(skb, sk);
return NF_ACCEPT;
}
@@ -306,7 +322,7 @@ tproxy_tg6_v1(struct sk_buff *skb, const struct xt_action_param *par)
par->in, NFT_LOOKUP_LISTENER);
/* NOTE: assign_sock consumes our sk reference */
- if (sk && nf_tproxy_assign_sock(skb, sk)) {
+ if (sk && tproxy_sk_is_transparent(sk)) {
/* This should be in a separate target, but we don't do multiple
targets on the same rule yet */
skb->mark = (skb->mark & ~tgi->mark_mask) ^ tgi->mark_value;
@@ -314,6 +330,8 @@ tproxy_tg6_v1(struct sk_buff *skb, const struct xt_action_param *par)
pr_debug("redirecting: proto %hhu %pI6:%hu -> %pI6:%hu, mark: %x\n",
tproto, &iph->saddr, ntohs(hp->source),
laddr, ntohs(lport), skb->mark);
+
+ nf_tproxy_assign_sock(skb, sk);
return NF_ACCEPT;
}
diff --git a/net/netfilter/xt_socket.c b/net/netfilter/xt_socket.c
index 00d6ae8..6d2226e 100644
--- a/net/netfilter/xt_socket.c
+++ b/net/netfilter/xt_socket.c
@@ -35,6 +35,15 @@
#include <net/netfilter/nf_conntrack.h>
#endif
+static void
+xt_socket_put_sk(struct sock *sk)
+{
+ if (sk->sk_state == TCP_TIME_WAIT)
+ inet_twsk_put(inet_twsk(sk));
+ else
+ sock_put(sk);
+}
+
static int
extract_icmp4_fields(const struct sk_buff *skb,
u8 *protocol,
@@ -164,7 +173,7 @@ socket_match(const struct sk_buff *skb, struct xt_action_param *par,
(sk->sk_state == TCP_TIME_WAIT &&
inet_twsk(sk)->tw_transparent));
- nf_tproxy_put_sock(sk);
+ xt_socket_put_sk(sk);
if (wildcard || !transparent)
sk = NULL;
@@ -298,7 +307,7 @@ socket_mt6_v1(const struct sk_buff *skb, struct xt_action_param *par)
(sk->sk_state == TCP_TIME_WAIT &&
inet_twsk(sk)->tw_transparent));
- nf_tproxy_put_sock(sk);
+ xt_socket_put_sk(sk);
if (wildcard || !transparent)
sk = NULL;
--
1.7.2.2
^ permalink raw reply related
* [PATCH] phy/micrel: add ability to support 50MHz RMII clock on KZS8051RNL
From: Baruch Siach @ 2011-02-14 12:05 UTC (permalink / raw)
To: netdev; +Cc: Baruch Siach, David J. Choi
Platform code can now set the MICREL_PHY_50MHZ_CLK bit of dev_flags in a fixup
routine (registered with phy_register_fixup_for_uid()), to make the KZS8051RNL
PHY work with 50MHz RMII reference clock.
Cc: David J. Choi <david.choi@micrel.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
---
drivers/net/phy/micrel.c | 24 ++++++++++++++++--------
include/linux/micrel_phy.h | 16 ++++++++++++++++
2 files changed, 32 insertions(+), 8 deletions(-)
create mode 100644 include/linux/micrel_phy.h
diff --git a/drivers/net/phy/micrel.c b/drivers/net/phy/micrel.c
index 8bb7db6..a6c3bf5 100644
--- a/drivers/net/phy/micrel.c
+++ b/drivers/net/phy/micrel.c
@@ -19,13 +19,7 @@
#include <linux/kernel.h>
#include <linux/module.h>
#include <linux/phy.h>
-
-#define PHY_ID_KSZ9021 0x00221611
-#define PHY_ID_KS8737 0x00221720
-#define PHY_ID_KS8041 0x00221510
-#define PHY_ID_KS8051 0x00221550
-/* both for ks8001 Rev. A/B, and for ks8721 Rev 3. */
-#define PHY_ID_KS8001 0x0022161A
+#include <linux/micrel_phy.h>
/* general Interrupt control/status reg in vendor specific block. */
#define MII_KSZPHY_INTCS 0x1B
@@ -46,6 +40,7 @@
#define KSZPHY_CTRL_INT_ACTIVE_HIGH (1 << 9)
#define KSZ9021_CTRL_INT_ACTIVE_HIGH (1 << 14)
#define KS8737_CTRL_INT_ACTIVE_HIGH (1 << 14)
+#define KSZ8051_RMII_50MHZ_CLK (1 << 7)
static int kszphy_ack_interrupt(struct phy_device *phydev)
{
@@ -106,6 +101,19 @@ static int kszphy_config_init(struct phy_device *phydev)
return 0;
}
+static int ks8051_config_init(struct phy_device *phydev)
+{
+ int regval;
+
+ if (phydev->dev_flags & MICREL_PHY_50MHZ_CLK) {
+ regval = phy_read(phydev, MII_KSZPHY_CTRL);
+ regval |= KSZ8051_RMII_50MHZ_CLK;
+ phy_write(phydev, MII_KSZPHY_CTRL, regval);
+ }
+
+ return 0;
+}
+
static struct phy_driver ks8737_driver = {
.phy_id = PHY_ID_KS8737,
.phy_id_mask = 0x00fffff0,
@@ -142,7 +150,7 @@ static struct phy_driver ks8051_driver = {
.features = (PHY_BASIC_FEATURES | SUPPORTED_Pause
| SUPPORTED_Asym_Pause),
.flags = PHY_HAS_MAGICANEG | PHY_HAS_INTERRUPT,
- .config_init = kszphy_config_init,
+ .config_init = ks8051_config_init,
.config_aneg = genphy_config_aneg,
.read_status = genphy_read_status,
.ack_interrupt = kszphy_ack_interrupt,
diff --git a/include/linux/micrel_phy.h b/include/linux/micrel_phy.h
new file mode 100644
index 0000000..dd8da34
--- /dev/null
+++ b/include/linux/micrel_phy.h
@@ -0,0 +1,16 @@
+#ifndef _MICREL_PHY_H
+#define _MICREL_PHY_H
+
+#define MICREL_PHY_ID_MASK 0x00fffff0
+
+#define PHY_ID_KSZ9021 0x00221611
+#define PHY_ID_KS8737 0x00221720
+#define PHY_ID_KS8041 0x00221510
+#define PHY_ID_KS8051 0x00221550
+/* both for ks8001 Rev. A/B, and for ks8721 Rev 3. */
+#define PHY_ID_KS8001 0x0022161A
+
+/* struct phy_device dev_flags definitions */
+#define MICREL_PHY_50MHZ_CLK 0x00000001
+
+#endif /* _MICREL_PHY_H */
--
1.7.2.3
^ permalink raw reply related
* Re: [PATCH] core: dev: don't call BUG() on bad input
From: Nicolas de Pesloüan @ 2011-02-14 12:16 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: linux-kernel, David S. Miller, Eric Dumazet, Tom Herbert,
Changli Gao, Jesse Gross, netdev
In-Reply-To: <1297680967-11893-1-git-send-email-segoon@openwall.com>
Le 14/02/2011 11:56, Vasiliy Kulikov a écrit :
> alloc_netdev() may be called with too long name (more that IFNAMSIZ bytes).
> Currently this leads to BUG(). Other insane inputs (bad txqs, rxqs) and
> even OOM don't lead to BUG(). Made alloc_netdev() return NULL, like on
> other errors.
>
> Signed-off-by: Vasiliy Kulikov<segoon@openwall.com>
> ---
> Compile tested.
>
> net/core/dev.c | 5 ++++-
> 1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 6392ea0..12ef4b0 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -5761,7 +5761,10 @@ struct net_device *alloc_netdev_mqs(int sizeof_priv, const char *name,
> size_t alloc_size;
> struct net_device *p;
>
> - BUG_ON(strlen(name)>= sizeof(dev->name));
> + if (strnlen(name, sizeof(dev->name))>= sizeof(dev->name)) {
"size_t strnlen(const char *s, size_t maxlen) : The strnlen() function returns strlen(s), if that is
less than maxlen, or maxlen if there is no '\0' character among the first maxlen characters pointed
to by s."
How can strnlen(name, sizeof(dev->name)) be greater than sizeof(dev->name)?
Shouldn't it be "if (strnlen(name, sizeof(dev->name)) == sizeof(dev->name))" instead?
Nicolas.
> + pr_err("alloc_netdev: Too long device name \n");
> + return NULL;
> + }
>
> if (txqs< 1) {
> pr_err("alloc_netdev: Unable to allocate device "
^ permalink raw reply
* Re: [PATCH] core: dev: don't call BUG() on bad input
From: Vasiliy Kulikov @ 2011-02-14 12:23 UTC (permalink / raw)
To: Nicolas de Pesloüan
Cc: linux-kernel, David S. Miller, Eric Dumazet, Tom Herbert,
Changli Gao, Jesse Gross, netdev
In-Reply-To: <4D591D04.4050000@gmail.com>
Hi Nicolas,
On Mon, Feb 14, 2011 at 13:16 +0100, Nicolas de Pesloüan wrote:
> >- BUG_ON(strlen(name)>= sizeof(dev->name));
> >+ if (strnlen(name, sizeof(dev->name))>= sizeof(dev->name)) {
Ehh... Space after ")" is needed :)
> "size_t strnlen(const char *s, size_t maxlen) : The strnlen()
> function returns strlen(s), if that is less than maxlen, or maxlen
> if there is no '\0' character among the first maxlen characters
> pointed to by s."
>
> How can strnlen(name, sizeof(dev->name)) be greater than sizeof(dev->name)?
>
> Shouldn't it be "if (strnlen(name, sizeof(dev->name)) == sizeof(dev->name))" instead?
Not a big deal, but MO it's better to guard from everything that
is not a good input by negating the check. strnlen() < sizeof() is OK,
strnlen() >= sizeof() is bad. Is "==" more preferable for net/ coding style?
--
Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments
^ permalink raw reply
* Re: [PATCH] core: dev: don't call BUG() on bad input
From: Nicolas de Pesloüan @ 2011-02-14 13:01 UTC (permalink / raw)
To: Vasiliy Kulikov
Cc: linux-kernel, David S. Miller, Eric Dumazet, Tom Herbert,
Changli Gao, Jesse Gross, netdev
In-Reply-To: <20110214122313.GA10062@albatros>
Le 14/02/2011 13:23, Vasiliy Kulikov a écrit :
> Hi Nicolas,
Hi Vasiliy,
> On Mon, Feb 14, 2011 at 13:16 +0100, Nicolas de Pesloüan wrote:
>>> - BUG_ON(strlen(name)>= sizeof(dev->name));
>>> + if (strnlen(name, sizeof(dev->name))>= sizeof(dev->name)) {
>
> Ehh... Space after ")" is needed :)
:-D
>> "size_t strnlen(const char *s, size_t maxlen) : The strnlen()
>> function returns strlen(s), if that is less than maxlen, or maxlen
>> if there is no '\0' character among the first maxlen characters
>> pointed to by s."
>>
>> How can strnlen(name, sizeof(dev->name)) be greater than sizeof(dev->name)?
>>
>> Shouldn't it be "if (strnlen(name, sizeof(dev->name)) == sizeof(dev->name))" instead?
>
> Not a big deal, but MO it's better to guard from everything that
> is not a good input by negating the check. strnlen()< sizeof() is OK,
> strnlen()>= sizeof() is bad. Is "==" more preferable for net/ coding style?
Agreed, both cannot cause any troubles. == is supposed to be better from the API point of view, but
>= is probably more readable.
Nicolas.
^ permalink raw reply
* (unknown),
From: robertjet.fellow @ 2011-02-14 11:45 UTC (permalink / raw)
My name is Mr. R. Jet Fellows. Am a citizen of the united states presently in Hong Kong where i have been diagnosed with Esophageal cancer and it has defied all forms of medical treatment, and right now I have only about a few months to live according to the medical experts.
Though am very rich, i never thought of raising my own family, I only focused on my businesses as that was the only thing I cared for. But now I regret all this as I now know that there is more to life than just wanting to have or make all the money in the world. The treatment of this disease has so far squashed a handsome amount of my money in savings.
Now that my health has deteriorated so badly and it has been confirmed to me by the doctors that my ailment will defy all forms of medical treatment, i have decided not to spend more money on this ailment anymore.
The last of my money which no one knows of is the huge cash deposit of $2.6m United States Dollars that I have with a Finance Vaulting Unit in the Europe . I will want you to help me collect this deposit from the company and help me distribute it to charity in your region. You will have 25% of this total sum for your time and effort. I cannot talk with you on the phone due to my health situation, and I am using my Laptop Computer to communicate with you, since this is my only means of communication. One passionate appeal i will make to you is to keep this transaction confidential until this money gets to you. If you are interested in carrying out this assignment on my behalf fill this form below when when writing me back.
Email: robertjet.fellow@gmail.com
Your names .......
Your resident address. ......
Your country name..........
Your present location........
Your occupation...............
Your tel/cell number.........
Your age/sex..................
Your company name if any.......
I will be waiting to hear from you as soon as you can.
Sincerely yours,
R. Jet Fellows.
^ permalink raw reply
* (unknown),
From: robertjet.fellow @ 2011-02-14 11:49 UTC (permalink / raw)
My name is Mr. R. Jet Fellows. Am a citizen of the united states presently in Hong Kong where i have been diagnosed with Esophageal cancer and it has defied all forms of medical treatment, and right now I have only about a few months to live according to the medical experts.
Though am very rich, i never thought of raising my own family, I only focused on my businesses as that was the only thing I cared for. But now I regret all this as I now know that there is more to life than just wanting to have or make all the money in the world. The treatment of this disease has so far squashed a handsome amount of my money in savings.
Now that my health has deteriorated so badly and it has been confirmed to me by the doctors that my ailment will defy all forms of medical treatment, i have decided not to spend more money on this ailment anymore.
The last of my money which no one knows of is the huge cash deposit of $2.6m United States Dollars that I have with a Finance Vaulting Unit in the Europe . I will want you to help me collect this deposit from the company and help me distribute it to charity in your region. You will have 25% of this total sum for your time and effort. I cannot talk with you on the phone due to my health situation, and I am using my Laptop Computer to communicate with you, since this is my only means of communication. One passionate appeal i will make to you is to keep this transaction confidential until this money gets to you. If you are interested in carrying out this assignment on my behalf fill this form below when when writing me back.
Email: robertjet.fellow@gmail.com
Your names .......
Your resident address. ......
Your country name..........
Your present location........
Your occupation...............
Your tel/cell number.........
Your age/sex..................
Your company name if any.......
I will be waiting to hear from you as soon as you can.
Sincerely yours,
R. Jet Fellows.
^ permalink raw reply
* Re: [RFC PATCH V2 0/5] macvtap TX zero copy between guest and host kernel
From: Michael S. Tsirkin @ 2011-02-14 13:09 UTC (permalink / raw)
To: Shirley Ma
Cc: Avi Kivity, Arnd Bergmann, xiaohui.xin, netdev, kvm, linux-kernel
In-Reply-To: <1291974691.2167.24.camel@localhost.localdomain>
On Fri, Dec 10, 2010 at 01:51:31AM -0800, Shirley Ma wrote:
> This patchset add supports for TX zero-copy between guest and host
> kernel through vhost. It significantly reduces CPU utilization on the
> local host on which the guest is located (It reduced 30-50% CPU usage
> for vhost thread for single stream test). The patchset is based on
> previous submission and comments from the community regarding when/how
> to handle guest kernel buffers to be released. This is the simplest
> approach I can think of after comparing with several other solutions.
>
> This patchset includes:
>
> 1. Induce a new sock zero-copy flag, SOCK_ZEROCOPY;
>
> 2. Induce a new device flag, NETIF_F_ZEROCOPY for device can support
> zero-copy;
>
> 3. Add a new struct skb_ubuf_info in skb_share_info for userspace
> buffers release callback when device DMA has done for that skb;
>
> 4. Add vhost zero-copy callback in vhost when skb last refcnt is gone;
> add vhost_zerocopy_add_used_and_signal to notify guest to release TX
> skb buffers.
>
> 5. Add macvtap zero-copy in lower device when sending packet is greater
> than 128 bytes.
>
> The patchset has passed netperf/netserver test on Chelsio, and
> continuing test on other 10GbE NICs, like Intel ixgbe, Mellanox mlx4...
> I will provide guest to host, host to guest performance data next week.
>
> However when running stress test, vhost & virtio_net seems out of sync,
> and virito_net interrupt was disabled somehow, and it stopped to send
> any packet. This problem has bothered me for a long long time, I will
> continue to look at this.
>
> Please review this.
>
> Thanks
> Shirley
What's the status here? Since there are core net changes, we'll need to
see the final version soon if it's to appear in 2.6.39.
Could the problem be related to the patch
virtio_net: Add schedule check to napi_enable call
?
Also, I expect there should be driver patches for some
devices? Where are they?
Thanks,
--
MST
^ permalink raw reply
* Re: [PATCH v2 09/13] can: pruss CAN driver.
From: Subhasish Ghosh @ 2011-02-14 13:15 UTC (permalink / raw)
To: Marc Kleine-Budde
Cc: sachi-EvXpCiN+lbve9wHmmfpqLFaTQe2KTcn/,
davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/,
open list:CAN NETWORK DRIVERS, nsekhar-l0cyMroinI0, open list,
open list:CAN NETWORK DRIVERS, Wolfgang Grandegger,
m-watkins-l0cyMroinI0,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <4D58F77B.9080005-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Hello,
The problem with the "all" implementation is that it hogs the ARM/DSP
heavily and that's the reason why we specifically avoided this in our
firmware design.
Hence, implementing this condition spoils the whole purpose of the PRU!!
--------------------------------------------------
From: "Marc Kleine-Budde" <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
Sent: Monday, February 14, 2011 3:05 PM
To: "Subhasish Ghosh" <subhasish-EvXpCiN+lbve9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
Cc: "Wolfgang Grandegger" <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>; "Kurt Van Dijck"
<kurt.van.dijck-/BeEPy95v10@public.gmane.org>; <davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org>;
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>; <m-watkins-l0cyMroinI0@public.gmane.org>;
<nsekhar-l0cyMroinI0@public.gmane.org>; <sachi-EvXpCiN+lbve9wHmmfpqLFaTQe2KTcn/@public.gmane.org>; "open list:CAN NETWORK
DRIVERS" <socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org>; "open list:CAN NETWORK DRIVERS"
<netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>; "open list" <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: Re: [PATCH v2 09/13] can: pruss CAN driver.
Hello,
On 02/14/2011 09:45 AM, Subhasish Ghosh wrote:
> That is correct, we receive only pre-programmed CAN ids and "all" or
> "range" implementation is not there in the PRU firmware.
I'd really like to see that you add a "all" implementation to the
firmware. Or even better use the standard id/mask approach.
cheers, Marc
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
^ permalink raw reply
* (unknown),
From: robertjet.fellow @ 2011-02-14 11:53 UTC (permalink / raw)
My name is Mr. R. Jet Fellows. Am a citizen of the united states presently in Hong Kong where i have been diagnosed with Esophageal cancer and it has defied all forms of medical treatment, and right now I have only about a few months to live according to the medical experts.
Though am very rich, i never thought of raising my own family, I only focused on my businesses as that was the only thing I cared for. But now I regret all this as I now know that there is more to life than just wanting to have or make all the money in the world. The treatment of this disease has so far squashed a handsome amount of my money in savings.
Now that my health has deteriorated so badly and it has been confirmed to me by the doctors that my ailment will defy all forms of medical treatment, i have decided not to spend more money on this ailment anymore.
The last of my money which no one knows of is the huge cash deposit of $2.6m United States Dollars that I have with a Finance Vaulting Unit in the Europe . I will want you to help me collect this deposit from the company and help me distribute it to charity in your region. You will have 25% of this total sum for your time and effort. I cannot talk with you on the phone due to my health situation, and I am using my Laptop Computer to communicate with you, since this is my only means of communication. One passionate appeal i will make to you is to keep this transaction confidential until this money gets to you. If you are interested in carrying out this assignment on my behalf fill this form below when when writing me back.
Email: robertjet.fellow@gmail.com
Your names .......
Your resident address. ......
Your country name..........
Your present location........
Your occupation...............
Your tel/cell number.........
Your age/sex..................
Your company name if any.......
I will be waiting to hear from you as soon as you can.
Sincerely yours,
R. Jet Fellows.
^ permalink raw reply
* Re: 2.6.37 regression: adding main interface to a bridge breaks vlan interface RX
From: chriss @ 2011-02-14 13:22 UTC (permalink / raw)
To: netdev
In-Reply-To: <4D4FE100.5090808@gmail.com>
Nicolas de Pesloüan <nicolas.2p.debian <at> gmail.com> writes:
> I think you should have a look at ebtables command, in particular, the
BROUTING chain of broute
> table. If this chain ask the packet to be dropped, then bridge will ignore it
and give a chance to
> the upper layer to use it. Upper layer might be IP, or in your particular
setup, VLAN.
>
> HTH,
>
> Nicolas.
Thank you very much for the ebtables hint.
I also tried to add the vlan to my bridge device but only droping the vlan
tagged paket with ebtables got it working.
I'm not sure if this is the wanted behavior for bridging vlan actions.
..or my network setup is just to ..f%%%'ed up?!
Thanks nicolas
regards//chriss
^ permalink raw reply
* Re: [PATCH v2 09/13] can: pruss CAN driver.
From: Marc Kleine-Budde @ 2011-02-14 13:33 UTC (permalink / raw)
To: Subhasish Ghosh
Cc: sachi-EvXpCiN+lbve9wHmmfpqLFaTQe2KTcn/,
davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/,
CAN NETWORK DRIVERS, nsekhar-l0cyMroinI0, open list,
CAN NETWORK DRIVERS, Wolfgang Grandegger, m-watkins-l0cyMroinI0,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <8CB9F2C8F75C4041B9F0691D209DDAFD@subhasishg>
[-- Attachment #1.1: Type: text/plain, Size: 1296 bytes --]
On 02/14/2011 02:15 PM, Subhasish Ghosh wrote:
> Hello,
>
> The problem with the "all" implementation is that it hogs the ARM/DSP
> heavily and that's the reason why we specifically avoided this in our
> firmware design.
> Hence, implementing this condition spoils the whole purpose of the PRU!!
What about implementing the standard id/mask approach?
if (canid & mask == id & mask)
aceept();
else
discard();
To keep the hot-path as small as possible, the id & mask operation is
done during setup, only one. This is probably just an additional "and"
operation (the "& mask"). This opens the way to act like a normal can
controller.
As long as we don't have any support for hardware filters in socketcan,
it's a good choice to use sysfs to configure your filters.
Have a look at [1] and [2] for how to use sysfs files.
cheers, Marc
[1]
http://git.kernel.org/linus/3a5655a5b545e9647c3437473ee3d815fe1b9050
[2]
http://git.kernel.org/linus/fef52b0171dfd7dd9b85c9cc201bd433b42a8ded
--
Pengutronix e.K. | Marc Kleine-Budde |
Industrial Linux Solutions | Phone: +49-231-2826-924 |
Vertretung West/Dortmund | Fax: +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686 | http://www.pengutronix.de |
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
[-- Attachment #2: Type: text/plain, Size: 188 bytes --]
_______________________________________________
Socketcan-core mailing list
Socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org
https://lists.berlios.de/mailman/listinfo/socketcan-core
^ permalink raw reply
* Re: [PATCH v2 09/13] can: pruss CAN driver.
From: Wolfgang Grandegger @ 2011-02-14 13:42 UTC (permalink / raw)
To: Subhasish Ghosh
Cc: sachi-EvXpCiN+lbve9wHmmfpqLFaTQe2KTcn/,
davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/,
CAN NETWORK DRIVERS, nsekhar-l0cyMroinI0, open list,
CAN NETWORK DRIVERS, Marc Kleine-Budde, m-watkins-l0cyMroinI0,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <8CB9F2C8F75C4041B9F0691D209DDAFD@subhasishg>
On 02/14/2011 02:15 PM, Subhasish Ghosh wrote:
> Hello,
>
> The problem with the "all" implementation is that it hogs the ARM/DSP
> heavily and that's the reason why we specifically avoided this in our
> firmware design.
> Hence, implementing this condition spoils the whole purpose of the PRU!!
Well, I doubt that a CAN controller just supporting 8 CAN identifiers
will make many CAN users happy. Anyway, the CAN identifiers could/should
be configured via SysFS files (as Marc suggested).
Wolfgang.
> --------------------------------------------------
> From: "Marc Kleine-Budde" <mkl-bIcnvbaLZ9MEGnE8C9+IrQ@public.gmane.org>
> Sent: Monday, February 14, 2011 3:05 PM
> To: "Subhasish Ghosh" <subhasish-EvXpCiN+lbve9wHmmfpqLFaTQe2KTcn/@public.gmane.org>
> Cc: "Wolfgang Grandegger" <wg-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>; "Kurt Van Dijck"
> <kurt.van.dijck-/BeEPy95v10@public.gmane.org>;
> <davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org>;
> <linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>; <m-watkins-l0cyMroinI0@public.gmane.org>;
> <nsekhar-l0cyMroinI0@public.gmane.org>; <sachi-EvXpCiN+lbve9wHmmfpqLFaTQe2KTcn/@public.gmane.org>; "open list:CAN NETWORK
> DRIVERS" <socketcan-core-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org>; "open list:CAN NETWORK
> DRIVERS" <netdev-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>; "open list"
> <linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
> Subject: Re: [PATCH v2 09/13] can: pruss CAN driver.
>
> Hello,
>
> On 02/14/2011 09:45 AM, Subhasish Ghosh wrote:
>> That is correct, we receive only pre-programmed CAN ids and "all" or
>> "range" implementation is not there in the PRU firmware.
>
> I'd really like to see that you add a "all" implementation to the
> firmware. Or even better use the standard id/mask approach.
>
> cheers, Marc
>
^ 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