* [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] 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] 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] 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] 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
* 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
* 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 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
* [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: 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
* 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 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 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
* [PATCH] net/can/softing: make CAN_SOFTING_CS depend on CAN_SOFTING
From: Kurt Van Dijck @ 2011-02-14 7:55 UTC (permalink / raw)
To: Randy Dunlap; +Cc: akpm, netdev, linux-kernel, davem
In-Reply-To: <4D56AF22.4070803@oracle.com>
The statement 'select CAN_SOFTING' may ignore the dependancies
for CAN_SOFTING while selecting CAN_SOFTING_CS, as is therefore a bad choice.
Signed-off-by: Kurt Van Dijck <kurt.van.dijck@eia.be>
Acked-by: Randy Dunlap <randy.dunlap@oracle.com>
---
diff --git a/drivers/net/can/softing/Kconfig b/drivers/net/can/softing/Kconfig
index 92bd6bd..55dd3e4 100644
--- a/drivers/net/can/softing/Kconfig
+++ b/drivers/net/can/softing/Kconfig
@@ -18,7 +18,7 @@ config CAN_SOFTING
config CAN_SOFTING_CS
tristate "Softing Gmbh CAN pcmcia cards"
depends on PCMCIA
- select CAN_SOFTING
+ depends on CAN_SOFTING
---help---
Support for PCMCIA cards from Softing Gmbh & some cards
from Vector Gmbh.
^ permalink raw reply related
* Re: [PATCH v2 09/13] can: pruss CAN driver.
From: Kurt Van Dijck @ 2011-02-14 7:42 UTC (permalink / raw)
To: Wolfgang Grandegger
Cc: sachi-EvXpCiN+lbve9wHmmfpqLFaTQe2KTcn/,
davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/,
Subhasish Ghosh, nsekhar-l0cyMroinI0, open list,
CAN NETWORK DRIVERS, CAN NETWORK DRIVERS, m-watkins-l0cyMroinI0,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <4D58D854.5090503-5Yr1BZd7O62+XT7JhA+gdA@public.gmane.org>
On Mon, Feb 14, 2011 at 08:23:00AM +0100, Wolfgang Grandegger wrote:
> 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-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org/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.
>
> Using SysFS files would already be much better.
Ack.
Kurt
^ permalink raw reply
* Re: linux-next: Tree for February 10 (netfilter)
From: Patrick McHardy @ 2011-02-14 7:34 UTC (permalink / raw)
To: Randy Dunlap
Cc: Stephen Rothwell, netdev, linux-next, LKML, netfilter-devel,
Thomas Graf
In-Reply-To: <20110210095210.6fcf3011.randy.dunlap@oracle.com>
On 10.02.2011 18:52, Randy Dunlap wrote:
> On Thu, 10 Feb 2011 18:05:25 +1100 Stephen Rothwell wrote:
>
>> Hi all,
>>
>> [The kernel.org mirroring is being slow ...]
>>
>> Changes since 20110209:
>
>
> xt_AUDIT.c:(.text+0x39ca9): undefined reference to `ipv6_skip_exthdr'
>
> IPV6 is not enabled.
>
> Full config file is attached.
Thomas, please have a look at this.
^ permalink raw reply
* Re: [PATCH net-next-2.6 v8 1/1] can: c_can: Added support for Bosch C_CAN controller
From: David Miller @ 2011-02-14 7:26 UTC (permalink / raw)
To: bhupesh.sharma-qxv4g6HH51o
Cc: Socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA, mkl-bIcnvbaLZ9MEGnE8C9+IrQ
In-Reply-To: <1297666006-8627-1-git-send-email-bhupesh.sharma-qxv4g6HH51o@public.gmane.org>
From: Bhupesh Sharma <bhupesh.sharma-qxv4g6HH51o@public.gmane.org>
Date: Mon, 14 Feb 2011 12:16:46 +0530
> Bosch C_CAN controller is a full-CAN implementation which is compliant
> to CAN protocol version 2.0 part A and B. Bosch C_CAN user manual can be
> obtained from:
> http://www.semiconductors.bosch.de/media/en/pdf/ipmodules_1/
> c_can/users_manual_c_can.pdf
>
> This patch adds the support for this controller.
> The following are the design choices made while writing the controller
> driver:
> 1. Interface Register set IF1 has be used only in the current design.
> 2. Out of the 32 Message objects available, 16 are kept aside for RX
> purposes and the rest for TX purposes.
> 3. NAPI implementation is such that both the TX and RX paths function
> in polling mode.
>
> Signed-off-by: Bhupesh Sharma <bhupesh.sharma-qxv4g6HH51o@public.gmane.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH 1/5] omap: panda: wlan board muxing
From: Ohad Ben-Cohen @ 2011-02-14 7:24 UTC (permalink / raw)
To: panduranga_mallireddy
Cc: coelho, netdev, linux-omap, linux-mmc, benzyg, pradeepgurumath,
vishalm, x-boudet, naveen_jain, pavan_savoy, manjunatha_halli,
tony, cjb
In-Reply-To: <1297667958-22377-2-git-send-email-panduranga_mallireddy@ti.com>
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 v2 09/13] can: pruss CAN driver.
From: Wolfgang Grandegger @ 2011-02-14 7:23 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: <C1C4300CE90A406FBDA2388D5491FAD5@subhasishg>
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-0fE9KPoRgkgATYTw5x5z8w@public.gmane.org/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
* [PATCH 5/5] OMAP: hsmmc: Enable MMC4 and MMC5 on OMAP4 platforms
From: panduranga_mallireddy @ 2011-02-14 7:19 UTC (permalink / raw)
To: coelho, netdev, linux-omap, linux-mmc
Cc: ohad, benzyg, pradeepgurumath, vishalm, x-boudet, naveen_jain,
pavan_savoy, manjunatha_halli, tony, cjb, Kishore Kadiyala,
Panduranga Mallireddy
In-Reply-To: <1297667958-22377-5-git-send-email-panduranga_mallireddy@ti.com>
From: Kishore Kadiyala <kishore.kadiyala@ti.com>
OMAP4 supports up to 5 MMC controllers, but only 3 of these were
initialized. MMC5 is used by wl12xx chip. So initialize MMC4 and MMC5.
Signed-off-by: Kishore Kadiyala <kishore.kadiyala@ti.com>
Signed-off-by: Panduranga Mallireddy <panduranga_mallireddy@ti.com>
---
arch/arm/mach-omap2/hsmmc.c | 5 +++++
drivers/mmc/host/omap_hsmmc.c | 24 ++++++++++++++++++++----
2 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-omap2/hsmmc.c b/arch/arm/mach-omap2/hsmmc.c
index 8f1a484..3c0809f 100644
--- a/arch/arm/mach-omap2/hsmmc.c
+++ b/arch/arm/mach-omap2/hsmmc.c
@@ -348,6 +348,11 @@ void __init omap2_hsmmc_init(struct omap2_hsmmc_info *controllers)
mmc->slots[0].after_set_reg = NULL;
}
break;
+ case 4:
+ case 5:
+ mmc->slots[0].before_set_reg = NULL;
+ mmc->slots[0].after_set_reg = NULL;
+ break;
default:
pr_err("MMC%d configuration not supported!\n", c->mmc);
kfree(mmc);
diff --git a/drivers/mmc/host/omap_hsmmc.c b/drivers/mmc/host/omap_hsmmc.c
index f59f8da..2525071 100644
--- a/drivers/mmc/host/omap_hsmmc.c
+++ b/drivers/mmc/host/omap_hsmmc.c
@@ -260,7 +260,7 @@ static int omap_hsmmc_1_set_power(struct device *dev, int slot, int power_on,
return ret;
}
-static int omap_hsmmc_23_set_power(struct device *dev, int slot, int power_on,
+static int omap_hsmmc_235_set_power(struct device *dev, int slot, int power_on,
int vdd)
{
struct omap_hsmmc_host *host =
@@ -316,6 +316,12 @@ static int omap_hsmmc_23_set_power(struct device *dev, int slot, int power_on,
return ret;
}
+static int omap_hsmmc_4_set_power(struct device *dev, int slot, int power_on,
+ int vdd)
+{
+ return 0;
+}
+
static int omap_hsmmc_1_set_sleep(struct device *dev, int slot, int sleep,
int vdd, int cardsleep)
{
@@ -326,7 +332,7 @@ static int omap_hsmmc_1_set_sleep(struct device *dev, int slot, int sleep,
return regulator_set_mode(host->vcc, mode);
}
-static int omap_hsmmc_23_set_sleep(struct device *dev, int slot, int sleep,
+static int omap_hsmmc_235_set_sleep(struct device *dev, int slot, int sleep,
int vdd, int cardsleep)
{
struct omap_hsmmc_host *host =
@@ -365,6 +371,12 @@ static int omap_hsmmc_23_set_sleep(struct device *dev, int slot, int sleep,
return regulator_enable(host->vcc_aux);
}
+static int omap_hsmmc_4_set_sleep(struct device *dev, int slot, int sleep,
+ int vdd, int cardsleep)
+{
+ return 0;
+}
+
static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
{
struct regulator *reg;
@@ -379,10 +391,14 @@ static int omap_hsmmc_reg_get(struct omap_hsmmc_host *host)
break;
case OMAP_MMC2_DEVID:
case OMAP_MMC3_DEVID:
+ case OMAP_MMC5_DEVID:
/* Off-chip level shifting, or none */
- mmc_slot(host).set_power = omap_hsmmc_23_set_power;
- mmc_slot(host).set_sleep = omap_hsmmc_23_set_sleep;
+ mmc_slot(host).set_power = omap_hsmmc_235_set_power;
+ mmc_slot(host).set_sleep = omap_hsmmc_235_set_sleep;
break;
+ case OMAP_MMC4_DEVID:
+ mmc_slot(host).set_power = omap_hsmmc_4_set_power;
+ mmc_slot(host).set_sleep = omap_hsmmc_4_set_sleep;
default:
pr_err("MMC%d configuration not supported!\n", host->id);
return -EINVAL;
--
1.5.6.3
^ permalink raw reply related
* [PATCH 4/5] omap: panda: add mmc5/wl1271 device support
From: panduranga_mallireddy @ 2011-02-14 7:19 UTC (permalink / raw)
To: coelho, netdev, linux-omap, linux-mmc
Cc: ohad, benzyg, pradeepgurumath, vishalm, x-boudet, naveen_jain,
pavan_savoy, manjunatha_halli, tony, cjb, Panduranga Mallireddy
In-Reply-To: <1297667958-22377-4-git-send-email-panduranga_mallireddy@ti.com>
From: Panduranga Mallireddy <panduranga_mallireddy@ti.com>
Add MMC5 support on PANDA, which has the wl1271 device hardwired to.
The wl1271 is a 4-wire, 1.8V, embedded SDIO WLAN device with an
external IRQ line, and power-controlled by a GPIO-based fixed regulator.
Based on the patch for mmc3/wl1271 device support for zoom by Ohad
Ben-Cohen <ohad@wizery.com>
Signed-off-by: Panduranga Mallireddy <panduranga_mallireddy@ti.com>
---
arch/arm/mach-omap2/board-omap4panda.c | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index cd25255..ef43010 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -27,6 +27,7 @@
#include <linux/i2c/twl.h>
#include <linux/regulator/machine.h>
#include <linux/regulator/fixed.h>
+#include <linux/wl12xx.h>
#include <mach/hardware.h>
#include <mach/omap4-common.h>
@@ -47,6 +48,7 @@
#define GPIO_HUB_POWER 1
#define GPIO_HUB_NRESET 62
#define GPIO_WIFI_PMENA 43
+#define GPIO_WIFI_IRQ 53
static struct gpio_led gpio_leds[] = {
{
@@ -164,6 +166,15 @@ static struct omap2_hsmmc_info mmc[] = {
.gpio_wp = -EINVAL,
.gpio_cd = -EINVAL,
},
+ {
+ .name = "wl1271",
+ .mmc = 5,
+ .caps = MMC_CAP_4_BIT_DATA | MMC_CAP_POWER_OFF_CARD,
+ .gpio_wp = -EINVAL,
+ .gpio_cd = -EINVAL,
+ .ocr_mask = MMC_VDD_165_195,
+ .nonremovable = true,
+ },
{} /* Terminator */
};
@@ -205,6 +216,12 @@ static struct platform_device omap_vwlan_device = {
},
};
+struct wl12xx_platform_data omap_panda_wlan_data __initdata = {
+ .irq = OMAP_GPIO_IRQ(GPIO_WIFI_IRQ),
+ /* PANDA ref clock is 38.4 MHz */
+ .board_ref_clock = 2,
+};
+
static int omap4_twl6030_hsmmc_late_init(struct device *dev)
{
int ret = 0;
@@ -461,6 +478,9 @@ static void __init omap4_panda_init(void)
package = OMAP_PACKAGE_CBL;
omap4_mux_init(board_mux, package);
+ if (wl12xx_set_platform_data(&omap_panda_wlan_data))
+ pr_err("error setting wl12xx data\n");
+
omap4_panda_i2c_init();
platform_add_devices(panda_devices, ARRAY_SIZE(panda_devices));
platform_device_register(&omap_vwlan_device);
--
1.5.6.3
^ permalink raw reply related
* [PATCH 3/5] omap: panda: add fixed regulator device for wlan
From: panduranga_mallireddy @ 2011-02-14 7:19 UTC (permalink / raw)
To: coelho, netdev, linux-omap, linux-mmc
Cc: ohad, benzyg, pradeepgurumath, vishalm, x-boudet, naveen_jain,
pavan_savoy, manjunatha_halli, tony, cjb, Panduranga Mallireddy
In-Reply-To: <1297667958-22377-3-git-send-email-panduranga_mallireddy@ti.com>
From: Panduranga Mallireddy <panduranga_mallireddy@ti.com>
Add a fixed regulator vmmc device to enable power control
of the wl1271 wlan device.
Based on the patch for zoom by Ohad Ben-Cohen <ohad@wizery.com>
Signed-off-by: Panduranga Mallireddy <panduranga_mallireddy@ti.com>
---
arch/arm/mach-omap2/board-omap4panda.c | 34 ++++++++++++++++++++++++++++++++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index cc9df6c..cd25255 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -26,6 +26,7 @@
#include <linux/usb/otg.h>
#include <linux/i2c/twl.h>
#include <linux/regulator/machine.h>
+#include <linux/regulator/fixed.h>
#include <mach/hardware.h>
#include <mach/omap4-common.h>
@@ -45,6 +46,7 @@
#define GPIO_HUB_POWER 1
#define GPIO_HUB_NRESET 62
+#define GPIO_WIFI_PMENA 43
static struct gpio_led gpio_leds[] = {
{
@@ -172,6 +174,37 @@ static struct regulator_consumer_supply omap4_panda_vmmc_supply[] = {
},
};
+static struct regulator_consumer_supply omap4_panda_vmmc5_supply = {
+ .supply = "vmmc",
+ .dev_name = "mmci-omap-hs.4",
+};
+
+static struct regulator_init_data panda_vmmc5 = {
+ .constraints = {
+ .valid_ops_mask = REGULATOR_CHANGE_STATUS,
+ },
+ .num_consumer_supplies = 1,
+ .consumer_supplies = &omap4_panda_vmmc5_supply,
+};
+
+static struct fixed_voltage_config panda_vwlan = {
+ .supply_name = "vwl1271",
+ .microvolts = 1800000, /* 1.8V */
+ .gpio = GPIO_WIFI_PMENA,
+ .startup_delay = 70000, /* 70msec */
+ .enable_high = 1,
+ .enabled_at_boot = 0,
+ .init_data = &panda_vmmc5,
+};
+
+static struct platform_device omap_vwlan_device = {
+ .name = "reg-fixed-voltage",
+ .id = 1,
+ .dev = {
+ .platform_data = &panda_vwlan,
+ },
+};
+
static int omap4_twl6030_hsmmc_late_init(struct device *dev)
{
int ret = 0;
@@ -430,6 +463,7 @@ static void __init omap4_panda_init(void)
omap4_panda_i2c_init();
platform_add_devices(panda_devices, ARRAY_SIZE(panda_devices));
+ platform_device_register(&omap_vwlan_device);
omap_serial_init();
omap4_twl6030_hsmmc_init(mmc);
/* OMAP4 Panda uses internal transceiver so register nop transceiver */
--
1.5.6.3
^ permalink raw reply related
* [PATCH 2/5] omap: select REGULATOR_FIXED_VOLTAGE by default for panda and sdp4430
From: panduranga_mallireddy @ 2011-02-14 7:19 UTC (permalink / raw)
To: coelho, netdev, linux-omap, linux-mmc
Cc: ohad, benzyg, pradeepgurumath, vishalm, x-boudet, naveen_jain,
pavan_savoy, manjunatha_halli, tony, cjb, Panduranga Mallireddy
In-Reply-To: <1297667958-22377-2-git-send-email-panduranga_mallireddy@ti.com>
From: Panduranga Mallireddy <panduranga_mallireddy@ti.com>
Power to the wl12xx wlan device is controlled by a fixed regulator.
Boards that have the wl12xx should select REGULATOR_FIXED_VOLTAGE.
Signed-off-by: Panduranga Mallireddy <panduranga_mallireddy@ti.com>
---
arch/arm/mach-omap2/Kconfig | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/Kconfig b/arch/arm/mach-omap2/Kconfig
index 1a2cf62..eeaeb3b 100644
--- a/arch/arm/mach-omap2/Kconfig
+++ b/arch/arm/mach-omap2/Kconfig
@@ -300,6 +300,7 @@ config MACH_OMAP_4430SDP
depends on ARCH_OMAP4
select OMAP_PACKAGE_CBL
select OMAP_PACKAGE_CBS
+ select REGULATOR_FIXED_VOLTAGE
config MACH_OMAP4_PANDA
bool "OMAP4 Panda Board"
@@ -307,6 +308,7 @@ config MACH_OMAP4_PANDA
depends on ARCH_OMAP4
select OMAP_PACKAGE_CBL
select OMAP_PACKAGE_CBS
+ select REGULATOR_FIXED_VOLTAGE
config OMAP3_EMU
bool "OMAP3 debugging peripherals"
--
1.5.6.3
^ permalink raw reply related
* [PATCH 1/5] omap: panda: wlan board muxing
From: panduranga_mallireddy @ 2011-02-14 7:19 UTC (permalink / raw)
To: coelho, netdev, linux-omap, linux-mmc
Cc: ohad, benzyg, pradeepgurumath, vishalm, x-boudet, naveen_jain,
pavan_savoy, manjunatha_halli, tony, cjb, Panduranga Mallireddy
In-Reply-To: <1297667958-22377-1-git-send-email-panduranga_mallireddy@ti.com>
From: Panduranga Mallireddy <panduranga_mallireddy@ti.com>
Add board muxing to support the wlan wl1271 chip that is
hardwired to mmc5 (fifth mmc controller) on the PANDA.
Based on the wlan board muxing for zoom3 by Ohad Ben-Cohen
<ohadb@ti.com>
Signed-off-by: Panduranga Mallireddy <panduranga_mallireddy@ti.com>
---
arch/arm/mach-omap2/board-omap4panda.c | 13 +++++++++++++
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/arch/arm/mach-omap2/board-omap4panda.c b/arch/arm/mach-omap2/board-omap4panda.c
index 9218862..cc9df6c 100644
--- a/arch/arm/mach-omap2/board-omap4panda.c
+++ b/arch/arm/mach-omap2/board-omap4panda.c
@@ -401,6 +401,19 @@ static int __init omap4_panda_i2c_init(void)
#ifdef CONFIG_OMAP_MUX
static struct omap_board_mux board_mux[] __initdata = {
+ /* WLAN IRQ - GPIO 53 */
+ OMAP4_MUX(GPMC_NCS3, OMAP_MUX_MODE3 | OMAP_PIN_INPUT_PULLUP),
+ /* WLAN POWER ENABLE - GPIO 43 */
+ OMAP4_MUX(GPMC_A19, OMAP_MUX_MODE3 | OMAP_PIN_OUTPUT),
+ /* WLAN SDIO: MMC5 CMD */
+ OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ /* WLAN SDIO: MMC5 CLK */
+ OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ /* WLAN SDIO: MMC5 DAT[0-3] */
+ OMAP4_MUX(SDMMC5_DAT0, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ OMAP4_MUX(SDMMC5_DAT1, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ OMAP4_MUX(SDMMC5_DAT2, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
+ OMAP4_MUX(SDMMC5_DAT3, OMAP_MUX_MODE0 | OMAP_PIN_INPUT_PULLUP),
{ .reg_offset = OMAP_MUX_TERMINATOR },
};
#else
--
1.5.6.3
^ permalink raw reply related
* [PATCH 0/5] Panda: Support for WLAN on WL127x
From: panduranga_mallireddy @ 2011-02-14 7:19 UTC (permalink / raw)
To: coelho, netdev, linux-omap, linux-mmc
Cc: ohad, benzyg, pradeepgurumath, vishalm, x-boudet, naveen_jain,
pavan_savoy, manjunatha_halli, tony, cjb, Panduranga Mallireddy
From: Panduranga Mallireddy <panduranga_mallireddy@ti.com>
Adding support for WLAN on Panda board using wl12xx and mac80211 drivers
Patches were tested on Panda board.
These patches add software control for emulating card detect events,
add board configurations to support the wl127x device.
These patches are dependent on the patches that enable clock for WLAN on panda.
Please refer the following links for these patches:
https://patchwork.kernel.org/patch/546381/
https://patchwork.kernel.org/patch/546401/
[PATCH 5/5] OMAP: hsmmc: Enable MMC4 and MMC5 on OMAP4 platforms
is dependent on hwmod adpotation for HSMMC patches series.
For original patches of adpotation for HSMMC refer:
http://www.mail-archive.com/linux-omap@vger.kernel.org/msg43464.html
Patches are based on mainline 2.6.38-rc3
Kishore Kadiyala (1):
OMAP: hsmmc: Enable MMC4 and MMC5 on OMAP4 platforms
Panduranga Mallireddy (4):
omap: panda: wlan board muxing
omap: select REGULATOR_FIXED_VOLTAGE by default for panda and sdp4430
omap: panda: add fixed regulator device for wlan
omap: panda: add mmc5/wl1271 device support
arch/arm/mach-omap2/Kconfig | 2 +
arch/arm/mach-omap2/board-omap4panda.c | 67 ++++++++++++++++++++++++++++++++
arch/arm/mach-omap2/hsmmc.c | 5 ++
drivers/mmc/host/omap_hsmmc.c | 24 +++++++++--
4 files changed, 94 insertions(+), 4 deletions(-)
^ 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