[PATCH] Staging: rtl8192u: r819xU_firmware_img.c Fixed checkpatch.pl ERRORs
Fixed a lot of errors of the type "ERROR: space required after that ','
(ctx:VxV)"
Signed-off-by: Chaitanya Hazarey
---
drivers/staging/rtl8192u/r819xU_firmware_img.c | 1036
1 file changed, 518 insertions(+), 518 deletions(-)
diff --git a/drivers/staging/rtl8192u/r819xU_firmware_img.c
b/drivers/staging/rtl8192u/r819xU_firmware_img.c
index 0785de7..19ab9a7 100644
--- a/drivers/staging/rtl8192u/r819xU_firmware_img.c
+++ b/drivers/staging/rtl8192u/r819xU_firmware_img.c
@@ -6,322 +6,322 @@ u32 Rtl8192UsbPHY_REGArray[] = {
0x0, };
u32 Rtl8192UsbPHY_REG_1T2RArray[] = {
-0x800,0x,
-0x804,0x0001,
-0x808,0xfc00,
-0x80c,0x001c,
-0x810,0x801010aa,
-0x814,0x008514d0,
-0x818,0x0040,
-0x81c,0x,
-0x820,0x0004,
-0x824,0x0069,
-0x828,0x0004,
-0x82c,0x00e9,
-0x830,0x0004,
-0x834,0x0069,
-0x838,0x0004,
-0x83c,0x00e9,
-0x840,0x,
-0x844,0x,
-0x848,0x,
-0x84c,0x,
-0x850,0x,
-0x854,0x,
-0x858,0x65a965a9,
-0x85c,0x65a965a9,
-0x860,0x001f0010,
-0x864,0x007f0010,
-0x868,0x001f0010,
-0x86c,0x007f0010,
-0x870,0x0f100f70,
-0x874,0x0f100f70,
-0x878,0x,
-0x87c,0x,
-0x880,0x6870e36c,
-0x884,0xe3573600,
-0x888,0x4260c340,
-0x88c,0xff00,
-0x890,0x,
-0x894,0xfffe,
-0x898,0x4c42382f,
-0x89c,0x00656056,
-0x8b0,0x,
-0x8e0,0x,
-0x8e4,0x,
-0x900,0x,
-0x904,0x0023,
-0x908,0x,
-0x90c,0x31121311,
-0xa00,0x00d0c7d8,
-0xa04,0x811f0008,
-0xa08,0x80cd8300,
-0xa0c,0x2e62740f,
-0xa10,0x95009b78,
-0xa14,0x11145008,
-0xa18,0x00881117,
-0xa1c,0x89140fa0,
-0xa20,0x1a1b,
-0xa24,0x090e1317,
-0xa28,0x0204,
-0xa2c,0x,
-0xc00,0x0040,
-0xc04,0x5433,
-0xc08,0x00e4,
-0xc0c,0x6c6c6c6c,
-0xc10,0x0880,
-0xc14,0x4100,
-0xc18,0x0800,
-0xc1c,0x4100,
-0xc20,0x0800,
-0xc24,0x4100,
-0xc28,0x0800,
-0xc2c,0x4100,
-0xc30,0x6de9ac44,
-0xc34,0x465c52cd,
-0xc38,0x497f5994,
-0xc3c,0x0a969764,
-0xc40,0x1f7c403f,
-0xc44,0x000100b7,
-0xc48,0xec02,
-0xc4c,0x0300,
-0xc50,0x69543420,
-0xc54,0x433c0094,
-0xc58,0x69543420,
-0xc5c,0x433c0094,
-0xc60,0x69543420,
-0xc64,0x433c0094,
-0xc68,0x69543420,
-0xc6c,0x433c0094,
-0xc70,0x2c7f000d,
-0xc74,0x0186175b,
-0xc78,0x001f,
-0xc7c,0x00b91612,
-0xc80,0x4100,
-0xc84,0x2000,
-0xc88,0x4100,
-0xc8c,0x2020,
-0xc90,0x4100,
-0xc94,0x,
-0xc98,0x4100,
-0xc9c,0x,
-0xca0,0x00492492,
-0xca4,0x,
-0xca8,0x,
-0xcac,0x,
-0xcb0,0x,
-0xcb4,0x,
-0xcb8,0x,
-0xcbc,0x00492492,
-0xcc0,0x,
-0xcc4,0x,
-0xcc8,0x,
-0xccc,0x,
-0xcd0,0x,
-0xcd4,0x,
-0xcd8,0x64b22427,
-0xcdc,0x00766932,
-0xce0,0x0022,
-0xd00,0x0750,
-0xd04,0x0403,
-0xd08,0x907f,
-0xd0c,0x0001,
-0xd10,0xa063,
-0xd14,0x3c63,
-0xd18,0x6a8f5b6b,
-0xd1c,0x,
-0xd20,0x,
-0xd24,0x,
-0xd28,0x,
-0xd2c,0xcc979975,
-0xd30,0x,
-0xd34,0x,
-0xd38,0x,
-0xd3c,0x00027293,
-0xd40,0x,
-0xd44,0x,
-0xd48,0x,
-0xd4c,0x,
-0xd50,0x6437140a,
-0xd54,0x024dbd02,
-0xd58,0x,
-0xd5c,0x04032064,
-0xe00,0x161a1a1a,
-0xe04,0x12121416,
-0xe08,0x1800,
-0xe0c,0x,
-0xe10,0x161a1a1a,
-0xe14,0x12121416,
-0xe18,0x161a1a1a,
-0xe1c,0x12121416,
+0x800, 0x,
+0x804, 0x0001,
+0x808, 0xfc00,
+0x80c, 0x001c,
+0x810, 0x801010aa,
+0x814, 0x008514d0,
+0x818, 0x0040,
+0x81c, 0x,
+0x820, 0x0004,
+0x824, 0x0069,
+0x828, 0x0004,
+0x82c, 0x00e9,
+0x830, 0x0004,
+0x834, 0x0069,
+0x838, 0x0004,
+0x83c, 0x00e9,
+0x840, 0x,
+0x844, 0x,
+0x848, 0x,
+0x84c, 0x,
+0x850, 0x,
+0x854, 0x,
+0x858, 0x65a965a9,
+0x85c, 0x65a965a9,
+0x860, 0x001f0010,
+0x864, 0x007f0010,
+0x868, 0x001f0010,
+0x86c, 0x007f0010,
+0x870, 0x0f100f70,
+0x874, 0x0f100f70,
+0x878, 0x,
+0x87c, 0x,
+0x880, 0x6870e36c,
+0x884, 0xe3573600,
+0x888, 0x4260c340,
+0x88c, 0xff00,
+0x890, 0x,
+0x894, 0xfffe,
+0x898, 0x4c42382f,
+0x89c, 0x00656056,
+0x8b0, 0x,
+0x8e0, 0x,
+0x8e4, 0x,
+0x900, 0x,
+0x904, 0x0023,
+0x908, 0x,
+0x90c, 0x31121311,
+0xa00, 0x00d0c7d8,
+0xa04, 0x811f0008,
+0xa08, 0x80cd8300,
+0xa0c, 0x2e62740f,
+0xa10, 0x95009b78,
+0xa14, 0x11145008,
+0xa18, 0x00881117,
+0xa1c, 0x89140fa0,
+0xa20, 0x1a1b,
+0xa24, 0x090e1317,
+0xa28, 0x0204,
+0xa2c, 0x,
+0xc00, 0x0040,
+0xc04, 0x5433,
+0xc08, 0x00e4,
+0xc0c, 0x6c6c6c6c,
+0xc10, 0x0880,
+0xc14, 0x4100,
+0xc18, 0x0800,
+0xc1c, 0x4100,
+0xc20, 0x0800,
+0xc24, 0x4100,
+0xc28, 0x0800,
+0xc2c, 0x4100,
+0xc30, 0x6de9ac44,
+0xc34, 0x465c52cd,
+0xc38, 0x497f5994,
+0xc3c, 0x0a969764,
+0xc40, 0x1f7c403f,
+0xc44, 0x000100b7,
+0xc48, 0xec02,
+0xc4c, 0x0300,
Greetings From Brian
I apologize for using this medium to reach out to you however, I am compelled by the urgency of my situation to contact you. I am a US Army Officer currently on mission in Libya. I would need your assistance to invest the sum of US$ 2.5M for me in your region. If you can offer me some guidelines and serve as my proxy investor in investing the funds, I will surely compensate you adequately. Kindly provide me with your direct phone number in your response to my private email so that we can discuss more in details. My private email is: shields...@gmail.com Best regards Brian Shields. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2 net-next 0/4] bridge: multicast snooping patches / exports
Changes in v2:
* fix a nasty typo in PATCH 1/4, br_multicast_update_query_timer():
"br->multicast_query_interval" vs. "br->multicast_querier_interval"
=> this accidentally reduced the other querier present timer
from 255 to 125 seconds
* fix a typo in PATCH 2/4, br_ip{4,6}_multicast_query():
ntohs(ETH_P_{IP,IPV6}) vs. htons(ETH_P_{IP,IPV6})
* add missing ntohl()s before address comparison in PATCH 2/4,
br_ip4_multicast_select_querier() (thanks David!)
Cheers, Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2 net-next 2/4] bridge: adhere to querier election mechanism specified by RFCs
MLDv1 (RFC2710 section 6), MLDv2 (RFC3810 section 7.6.2), IGMPv2
(RFC2236 section 3) and IGMPv3 (RFC3376 section 6.6.2) specify that the
querier with lowest source address shall become the selected
querier.
So far the bridge stopped its querier as soon as it heard another
querier regardless of its source address. This results in the "wrong"
querier potentially becoming the active querier or a potential,
unnecessary querying delay.
With this patch the bridge memorizes the source address of the currently
selected querier and ignores queries from queriers with a higher source
address than the currently selected one. This slight optimization is
supposed to make it more RFC compliant (but is rather uncritical and
therefore probably not necessary to be queued for stable kernels).
Signed-off-by: Linus Lüssing
---
net/bridge/br_multicast.c | 101 +++--
net/bridge/br_private.h |7
2 files changed, 95 insertions(+), 13 deletions(-)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 5ccac62..b3f17c9 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -789,6 +789,18 @@ static void br_ip6_multicast_querier_expired(unsigned long
data)
}
#endif
+static void br_multicast_select_own_querier(struct net_bridge *br,
+ struct br_ip *ip,
+ struct sk_buff *skb)
+{
+ if (ip->proto == htons(ETH_P_IP))
+ br->ip4_querier.addr.u.ip4 = ip_hdr(skb)->saddr;
+#if IS_ENABLED(CONFIG_IPV6)
+ else
+ br->ip6_querier.addr.u.ip6 = ipv6_hdr(skb)->saddr;
+#endif
+}
+
static void __br_multicast_send_query(struct net_bridge *br,
struct net_bridge_port *port,
struct br_ip *ip)
@@ -804,8 +816,10 @@ static void __br_multicast_send_query(struct net_bridge
*br,
skb->dev = port->dev;
NF_HOOK(NFPROTO_BRIDGE, NF_BR_LOCAL_OUT, skb, NULL, skb->dev,
dev_queue_xmit);
- } else
+ } else {
+ br_multicast_select_own_querier(br, ip, skb);
netif_rx(skb);
+ }
}
static void br_multicast_send_query(struct net_bridge *br,
@@ -1065,6 +1079,62 @@ static int br_ip6_multicast_mld2_report(struct
net_bridge *br,
}
#endif
+static bool br_ip4_multicast_select_querier(struct net_bridge *br,
+ __be32 saddr)
+{
+ if (!timer_pending(>ip4_own_query.timer) &&
+ !timer_pending(>ip4_other_query.timer))
+ goto update;
+
+ if (!br->ip4_querier.addr.u.ip4)
+ goto update;
+
+ if (ntohl(saddr) <= ntohl(br->ip4_querier.addr.u.ip4))
+ goto update;
+
+ return false;
+
+update:
+ br->ip4_querier.addr.u.ip4 = saddr;
+
+ return true;
+}
+
+#if IS_ENABLED(CONFIG_IPV6)
+static bool br_ip6_multicast_select_querier(struct net_bridge *br,
+ struct in6_addr *saddr)
+{
+ if (!timer_pending(>ip6_own_query.timer) &&
+ !timer_pending(>ip6_other_query.timer))
+ goto update;
+
+ if (ipv6_addr_cmp(saddr, >ip6_querier.addr.u.ip6) <= 0)
+ goto update;
+
+ return false;
+
+update:
+ br->ip6_querier.addr.u.ip6 = *saddr;
+
+ return true;
+}
+#endif
+
+static bool br_multicast_select_querier(struct net_bridge *br,
+ struct br_ip *saddr)
+{
+ switch (saddr->proto) {
+ case htons(ETH_P_IP):
+ return br_ip4_multicast_select_querier(br, saddr->u.ip4);
+#if IS_ENABLED(CONFIG_IPV6)
+ case htons(ETH_P_IPV6):
+ return br_ip6_multicast_select_querier(br, >u.ip6);
+#endif
+ }
+
+ return false;
+}
+
static void
br_multicast_update_query_timer(struct net_bridge *br,
struct bridge_mcast_other_query *query,
@@ -1127,15 +1197,13 @@ timer:
static void br_multicast_query_received(struct net_bridge *br,
struct net_bridge_port *port,
struct bridge_mcast_other_query *query,
- int saddr,
- bool is_general_query,
+ struct br_ip *saddr,
unsigned long max_delay)
{
- if (saddr && is_general_query)
- br_multicast_update_query_timer(br, query, max_delay);
- else if (timer_pending(>timer))
+ if (!br_multicast_select_querier(br, saddr))
return;
+ br_multicast_update_query_timer(br, query, max_delay);
br_multicast_mark_router(br, port);
}
@@ -1150,6 +1218,7 @@ static int br_ip4_multicast_query(struct net_bridge *br,
struct igmpv3_query *ih3;
struct
[PATCHv2 net-next 3/4] bridge: add export of multicast database adjacent to net_dev
With this new, exported function br_multicast_list_adjacent(net_dev) a
list of IPv4/6 addresses is returned. This list contains all multicast
addresses sensed by the bridge multicast snooping feature on all bridge
ports of the bridge interface of net_dev, excluding addresses from the
specified net_device itself.
Adding bridge support to the batman-adv multicast optimization requires
batman-adv knowing about the existence of bridged-in multicast
listeners to be able to reliably serve them with multicast packets.
Signed-off-by: Linus Lüssing
---
include/linux/if_bridge.h | 18 ++
net/bridge/br_multicast.c | 58 +
net/bridge/br_private.h | 12 --
3 files changed, 76 insertions(+), 12 deletions(-)
diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
index 1085ffe..44d6eb0 100644
--- a/include/linux/if_bridge.h
+++ b/include/linux/if_bridge.h
@@ -16,9 +16,27 @@
#include
#include
+struct br_ip {
+ union {
+ __be32 ip4;
+#if IS_ENABLED(CONFIG_IPV6)
+ struct in6_addr ip6;
+#endif
+ } u;
+ __be16 proto;
+ __u16 vid;
+};
+
+struct br_ip_list {
+ struct list_head list;
+ struct br_ip addr;
+};
+
extern void brioctl_set(int (*ioctl_hook)(struct net *, unsigned int, void
__user *));
typedef int br_should_route_hook_t(struct sk_buff *skb);
extern br_should_route_hook_t __rcu *br_should_route_hook;
+int br_multicast_list_adjacent(struct net_device *dev,
+ struct list_head *br_ip_list);
#endif
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index b3f17c9..807e535 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -11,6 +11,7 @@
*/
#include
+#include
#include
#include
#include
@@ -2141,3 +2142,60 @@ unlock:
return err;
}
+
+/**
+ * br_multicast_list_adjacent - Returns snooped multicast addresses
+ * @dev: The bridge port adjacent to which to retrieve addresses
+ * @br_ip_list:The list to store found, snooped multicast IP addresses
in
+ *
+ * Creates a list of IP addresses (struct br_ip_list) sensed by the multicast
+ * snooping feature on all bridge ports of dev's bridge device, excluding
+ * the addresses from dev itself.
+ *
+ * Returns the number of items added to br_ip_list.
+ *
+ * Notes:
+ * - br_ip_list needs to be initialized by caller
+ * - br_ip_list might contain duplicates in the end
+ * (needs to be taken care of by caller)
+ * - br_ip_list needs to be freed by caller
+ */
+int br_multicast_list_adjacent(struct net_device *dev,
+ struct list_head *br_ip_list)
+{
+ struct net_bridge *br;
+ struct net_bridge_port *port;
+ struct net_bridge_port_group *group;
+ struct br_ip_list *entry;
+ int count = 0;
+
+ rcu_read_lock();
+ if (!br_ip_list || !br_port_exists(dev))
+ goto unlock;
+
+ port = br_port_get_rcu(dev);
+ if (!port || !port->br)
+ goto unlock;
+
+ br = port->br;
+
+ list_for_each_entry_rcu(port, >port_list, list) {
+ if (!port->dev || port->dev == dev)
+ continue;
+
+ hlist_for_each_entry_rcu(group, >mglist, mglist) {
+ entry = kmalloc(sizeof(*entry), GFP_ATOMIC);
+ if (!entry)
+ goto unlock;
+
+ entry->addr = group->addr;
+ list_add(>list, br_ip_list);
+ count++;
+ }
+ }
+
+unlock:
+ rcu_read_unlock();
+ return count;
+}
+EXPORT_SYMBOL(br_multicast_list_adjacent);
diff --git a/net/bridge/br_private.h b/net/bridge/br_private.h
index bc1803b..cb704a6 100644
--- a/net/bridge/br_private.h
+++ b/net/bridge/br_private.h
@@ -54,18 +54,6 @@ struct mac_addr
unsigned char addr[ETH_ALEN];
};
-struct br_ip
-{
- union {
- __be32 ip4;
-#if IS_ENABLED(CONFIG_IPV6)
- struct in6_addr ip6;
-#endif
- } u;
- __be16 proto;
- __u16 vid;
-};
-
#ifdef CONFIG_BRIDGE_IGMP_SNOOPING
/* our own querier */
struct bridge_mcast_own_query {
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2 net-next 1/4] bridge: rename struct bridge_mcast_query/querier
The current naming of these two structs is very random, in that
reversing their naming would not make any semantical difference.
This patch tries to make the naming less confusing by giving them a more
specific, distinguishable naming.
This is also useful for the upcoming patches reintroducing the
"struct bridge_mcast_querier" but for storing information about the
selected querier (no matter if our own or a foreign querier).
Signed-off-by: Linus Lüssing
---
net/bridge/br_mdb.c |4 +-
net/bridge/br_multicast.c | 169 +++--
net/bridge/br_private.h | 22 +++---
3 files changed, 100 insertions(+), 95 deletions(-)
diff --git a/net/bridge/br_mdb.c b/net/bridge/br_mdb.c
index b7b1914..5df0526 100644
--- a/net/bridge/br_mdb.c
+++ b/net/bridge/br_mdb.c
@@ -418,13 +418,13 @@ static int __br_mdb_del(struct net_bridge *br, struct
br_mdb_entry *entry)
ip.proto = entry->addr.proto;
if (ip.proto == htons(ETH_P_IP)) {
- if (timer_pending(>ip4_querier.timer))
+ if (timer_pending(>ip4_other_query.timer))
return -EBUSY;
ip.u.ip4 = entry->addr.u.ip4;
#if IS_ENABLED(CONFIG_IPV6)
} else {
- if (timer_pending(>ip6_querier.timer))
+ if (timer_pending(>ip6_other_query.timer))
return -EBUSY;
ip.u.ip6 = entry->addr.u.ip6;
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 7b757b5..5ccac62 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -35,7 +35,7 @@
#include "br_private.h"
static void br_multicast_start_querier(struct net_bridge *br,
- struct bridge_mcast_query *query);
+ struct bridge_mcast_own_query *query);
unsigned int br_mdb_rehash_seq;
static inline int br_ip_equal(const struct br_ip *a, const struct br_ip *b)
@@ -761,7 +761,7 @@ static void br_multicast_local_router_expired(unsigned long
data)
}
static void br_multicast_querier_expired(struct net_bridge *br,
-struct bridge_mcast_query *query)
+struct bridge_mcast_own_query *query)
{
spin_lock(>multicast_lock);
if (!netif_running(br->dev) || br->multicast_disabled)
@@ -777,7 +777,7 @@ static void br_ip4_multicast_querier_expired(unsigned long
data)
{
struct net_bridge *br = (void *)data;
- br_multicast_querier_expired(br, >ip4_query);
+ br_multicast_querier_expired(br, >ip4_own_query);
}
#if IS_ENABLED(CONFIG_IPV6)
@@ -785,7 +785,7 @@ static void br_ip6_multicast_querier_expired(unsigned long
data)
{
struct net_bridge *br = (void *)data;
- br_multicast_querier_expired(br, >ip6_query);
+ br_multicast_querier_expired(br, >ip6_own_query);
}
#endif
@@ -810,11 +810,11 @@ static void __br_multicast_send_query(struct net_bridge
*br,
static void br_multicast_send_query(struct net_bridge *br,
struct net_bridge_port *port,
- struct bridge_mcast_query *query)
+ struct bridge_mcast_own_query *own_query)
{
unsigned long time;
struct br_ip br_group;
- struct bridge_mcast_querier *querier = NULL;
+ struct bridge_mcast_other_query *other_query = NULL;
if (!netif_running(br->dev) || br->multicast_disabled ||
!br->multicast_querier)
@@ -822,31 +822,32 @@ static void br_multicast_send_query(struct net_bridge *br,
memset(_group.u, 0, sizeof(br_group.u));
- if (port ? (query == >ip4_query) :
- (query == >ip4_query)) {
- querier = >ip4_querier;
+ if (port ? (own_query == >ip4_own_query) :
+ (own_query == >ip4_own_query)) {
+ other_query = >ip4_other_query;
br_group.proto = htons(ETH_P_IP);
#if IS_ENABLED(CONFIG_IPV6)
} else {
- querier = >ip6_querier;
+ other_query = >ip6_other_query;
br_group.proto = htons(ETH_P_IPV6);
#endif
}
- if (!querier || timer_pending(>timer))
+ if (!other_query || timer_pending(_query->timer))
return;
__br_multicast_send_query(br, port, _group);
time = jiffies;
- time += query->startup_sent < br->multicast_startup_query_count ?
+ time += own_query->startup_sent < br->multicast_startup_query_count ?
br->multicast_startup_query_interval :
br->multicast_query_interval;
- mod_timer(>timer, time);
+ mod_timer(_query->timer, time);
}
-static void br_multicast_port_query_expired(struct net_bridge_port *port,
- struct bridge_mcast_query *query)
+static void
+br_multicast_port_query_expired(struct
[PATCHv2 net-next 4/4] bridge: memorize and export selected IGMP/MLD querier port
Adding bridge support to the batman-adv multicast optimization requires
batman-adv knowing about the existence of bridged-in IGMP/MLD queriers
to be able to reliably serve any multicast listener behind this same
bridge.
Signed-off-by: Linus Lüssing
---
include/linux/if_bridge.h |1 +
net/bridge/br_multicast.c | 72 +
net/bridge/br_private.h |1 +
3 files changed, 68 insertions(+), 6 deletions(-)
diff --git a/include/linux/if_bridge.h b/include/linux/if_bridge.h
index 44d6eb0..fd22789 100644
--- a/include/linux/if_bridge.h
+++ b/include/linux/if_bridge.h
@@ -38,5 +38,6 @@ typedef int br_should_route_hook_t(struct sk_buff *skb);
extern br_should_route_hook_t __rcu *br_should_route_hook;
int br_multicast_list_adjacent(struct net_device *dev,
struct list_head *br_ip_list);
+bool br_multicast_has_querier_adjacent(struct net_device *dev, int proto);
#endif
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index 807e535..3c9b405 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -1081,6 +1081,7 @@ static int br_ip6_multicast_mld2_report(struct net_bridge
*br,
#endif
static bool br_ip4_multicast_select_querier(struct net_bridge *br,
+ struct net_bridge_port *port,
__be32 saddr)
{
if (!timer_pending(>ip4_own_query.timer) &&
@@ -1098,11 +1099,15 @@ static bool br_ip4_multicast_select_querier(struct
net_bridge *br,
update:
br->ip4_querier.addr.u.ip4 = saddr;
+ /* update protected by general multicast_lock by caller */
+ rcu_assign_pointer(br->ip4_querier.port, port);
+
return true;
}
#if IS_ENABLED(CONFIG_IPV6)
static bool br_ip6_multicast_select_querier(struct net_bridge *br,
+ struct net_bridge_port *port,
struct in6_addr *saddr)
{
if (!timer_pending(>ip6_own_query.timer) &&
@@ -1117,19 +1122,23 @@ static bool br_ip6_multicast_select_querier(struct
net_bridge *br,
update:
br->ip6_querier.addr.u.ip6 = *saddr;
+ /* update protected by general multicast_lock by caller */
+ rcu_assign_pointer(br->ip6_querier.port, port);
+
return true;
}
#endif
static bool br_multicast_select_querier(struct net_bridge *br,
+ struct net_bridge_port *port,
struct br_ip *saddr)
{
switch (saddr->proto) {
case htons(ETH_P_IP):
- return br_ip4_multicast_select_querier(br, saddr->u.ip4);
+ return br_ip4_multicast_select_querier(br, port, saddr->u.ip4);
#if IS_ENABLED(CONFIG_IPV6)
case htons(ETH_P_IPV6):
- return br_ip6_multicast_select_querier(br, >u.ip6);
+ return br_ip6_multicast_select_querier(br, port, >u.ip6);
#endif
}
@@ -1201,7 +1210,7 @@ static void br_multicast_query_received(struct net_bridge
*br,
struct br_ip *saddr,
unsigned long max_delay)
{
- if (!br_multicast_select_querier(br, saddr))
+ if (!br_multicast_select_querier(br, port, saddr))
return;
br_multicast_update_query_timer(br, query, max_delay);
@@ -1804,12 +1813,14 @@ int br_multicast_rcv(struct net_bridge *br, struct
net_bridge_port *port,
}
static void br_multicast_query_expired(struct net_bridge *br,
- struct bridge_mcast_own_query *query)
+ struct bridge_mcast_own_query *query,
+ struct bridge_mcast_querier *querier)
{
spin_lock(>multicast_lock);
if (query->startup_sent < br->multicast_startup_query_count)
query->startup_sent++;
+ rcu_assign_pointer(querier, NULL);
br_multicast_send_query(br, NULL, query);
spin_unlock(>multicast_lock);
}
@@ -1818,7 +1829,7 @@ static void br_ip4_multicast_query_expired(unsigned long
data)
{
struct net_bridge *br = (void *)data;
- br_multicast_query_expired(br, >ip4_own_query);
+ br_multicast_query_expired(br, >ip4_own_query, >ip4_querier);
}
#if IS_ENABLED(CONFIG_IPV6)
@@ -1826,7 +1837,7 @@ static void br_ip6_multicast_query_expired(unsigned long
data)
{
struct net_bridge *br = (void *)data;
- br_multicast_query_expired(br, >ip6_own_query);
+ br_multicast_query_expired(br, >ip6_own_query, >ip6_querier);
}
#endif
@@ -1849,8 +1860,10 @@ void br_multicast_init(struct net_bridge *br)
br->multicast_membership_interval = 260 * HZ;
br->ip4_other_query.delay_time = 0;
+ br->ip4_querier.port = NULL;
#if IS_ENABLED(CONFIG_IPV6)
br->ip6_other_query.delay_time = 0;
+ br->ip6_querier.port = NULL;
[PATCH] perf: fix 'make help' message error
Currently 'make help' message has such hint: use "make prefix= " to install to a particular path like make prefix=/usr/local install install-doc But this is misleading, when I specify "prefix=/usr/local", it has got no respect at all. Instead, what takes effect is the "DESTDIR" variable. In this case, "DESTDIR" has a empty value, so the actual install directory falls back $HOME, not '/usr/local'. Specifying "DESTDIR=/usr/local" will work as desired. This patch fixes the help message. Signed-off-by: Jianyu Zhan --- tools/perf/Makefile.perf | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf index 895edd3..37c5f90 100644 --- a/tools/perf/Makefile.perf +++ b/tools/perf/Makefile.perf @@ -784,8 +784,8 @@ help: @echo '' @echo 'Perf install targets:' @echo ' NOTE: documentation build requires asciidoc, xmlto packages to be installed' - @echo ' HINT: use "make prefix= " to install to a particular' - @echo 'path like make prefix=/usr/local install install-doc' + @echo ' HINT: use "make DESTDIR= " to install to a particular' + @echo 'path like "make DESTDIR=/usr/local install install-doc"' @echo ' install- install compiled binaries' @echo ' install-doc- install *all* documentation' @echo ' install-man- install manpage documentation' -- 2.0.0-rc3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] lib/debugobjects.c: convert printk to pr_foo()
On Sun, May 25, 2014 at 05:18:36AM +0200, Fabian Frederick wrote: > On Sat, 24 May 2014 14:53:22 -0700 > Josh Triplett wrote: > > > On Sat, May 24, 2014 at 03:06:08PM +0200, Fabian Frederick wrote: > > > Convert all except KERN_DEBUG > > > > Why not KERN_DEBUG? > printk(KERN_DEBUG can't be converted to pr_debug the same way as other printk. True, but I don't see any obvious reason why that prevents you from converting them. More importantly, though, you should explain for the benefit of the changelog. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] net: driver: stmicro: Remove some useless the lock protection
From: Date: Sun, 25 May 2014 09:53:44 +0800 > From: Yang Wei > > kernel always invokes a pair of rtnl_lock adn rtnl_unlock to > protect dev_ethtool(), so its not neccessary to invoke spin_lock/unlock > in ethtool_ops. > > Signed-off-by: Yang Wei Applied to net-next, thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] lib/debugobjects.c: move __initdata after name
Adding Andy and Joe to CC.
On Sun, May 25, 2014 at 05:13:38AM +0200, Fabian Frederick wrote:
> On Sat, 24 May 2014 14:56:35 -0700
> Josh Triplett wrote:
>
> > On Sat, May 24, 2014 at 03:07:19PM +0200, Fabian Frederick wrote:
> > > Cc: Josh Triplett
> > > Cc: Andrew Morton
> > > Signed-off-by: Fabian Frederick
> >
> > No, don't make this change. A quick "git grep __initdata" shows that to
> > the extent it has a consistent placement, it's either right after the
> > type ("static some_type __initdata varname") or right after the storage
> > class ("static __initdata some_type varname"). Other similar qualifiers
> > follow the same pattern.
>
> It was another checkpatch warning asking to put __initdata after variable
> name...
Gah. That warning should not exist. Looks like it got added in
8716de383b82f16d920513138f1691e40ef5a9e3 ("checkpatch: add test for
positional misuse of section specifiers like __initdata"). The error
for placement that GCC doesn't understand seems perfectly fine, but
checkpatch should *not* complain about "static __initdata struct foo
..."; that's perfectly understandable, and the order the majority of the
kernel uses. Please get rid of that warning, and just keep the error
for the case GCC doesn't understand.
- Josh Triplett
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] lib/debugobjects.c: convert printk to pr_foo()
On Sat, 24 May 2014 14:53:22 -0700 Josh Triplett wrote: > On Sat, May 24, 2014 at 03:06:08PM +0200, Fabian Frederick wrote: > > Convert all except KERN_DEBUG > > Why not KERN_DEBUG? printk(KERN_DEBUG can't be converted to pr_debug the same way as other printk. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] lib/debugobjects.c: code clean-up
On Sat, 24 May 2014 15:00:09 -0700 Josh Triplett wrote: > On Sat, May 24, 2014 at 03:08:06PM +0200, Fabian Frederick wrote: > > Fix some checkpatch warnings. > > > > Cc: Josh Triplett > > Cc: Andrew Morton > > Signed-off-by: Fabian Frederick > > Some of these make sense, one of them does not. Comments below. > > Also, please explicitly note the checkpatch warnings you fixed, not just > "Fix some checkpatch warnings.". ok -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] lib/debugobjects.c: move __initdata after name
On Sat, 24 May 2014 14:56:35 -0700
Josh Triplett wrote:
> On Sat, May 24, 2014 at 03:07:19PM +0200, Fabian Frederick wrote:
> > Cc: Josh Triplett
> > Cc: Andrew Morton
> > Signed-off-by: Fabian Frederick
>
> No, don't make this change. A quick "git grep __initdata" shows that to
> the extent it has a consistent placement, it's either right after the
> type ("static some_type __initdata varname") or right after the storage
> class ("static __initdata some_type varname"). Other similar qualifiers
> follow the same pattern.
It was another checkpatch warning asking to put __initdata after variable
name...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] net: driver: stmicro: Remove some useless the lock protection
From: Yang Wei kernel always invokes a pair of rtnl_lock adn rtnl_unlock to protect dev_ethtool(), so its not neccessary to invoke spin_lock/unlock in ethtool_ops. Signed-off-by: Yang Wei --- Hi David, I regenerate this patch based on net/next repo in v2. Wei .../net/ethernet/stmicro/stmmac/stmmac_ethtool.c |6 -- 1 file changed, 6 deletions(-) diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c index c963394..7892666 100644 --- a/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_ethtool.c @@ -322,9 +322,7 @@ static int stmmac_ethtool_getsettings(struct net_device *dev, return -EBUSY; } cmd->transceiver = XCVR_INTERNAL; - spin_lock_irq(>lock); rc = phy_ethtool_gset(phy, cmd); - spin_unlock_irq(>lock); return rc; } @@ -442,7 +440,6 @@ stmmac_get_pauseparam(struct net_device *netdev, if (priv->flow_ctrl & FLOW_TX) pause->tx_pause = 1; - spin_unlock(>lock); } static int @@ -457,8 +454,6 @@ stmmac_set_pauseparam(struct net_device *netdev, if (priv->pcs) /* FIXME */ return -EOPNOTSUPP; - spin_lock(>lock); - if (pause->rx_pause) new_pause |= FLOW_RX; if (pause->tx_pause) @@ -473,7 +468,6 @@ stmmac_set_pauseparam(struct net_device *netdev, } else priv->hw->mac->flow_ctrl(priv->ioaddr, phy->duplex, priv->flow_ctrl, priv->pause); - spin_unlock(>lock); return ret; } -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[FIX] [CRITICAL] Re: [PATCH] clk: divider: Fix overflow in clk_divider_bestdiv
Mike,
On 15.05.2014 18:51, Tomasz Figa wrote:
> Hi Mike,
>
> On 07.05.2014 18:24, Tomasz Figa wrote:
>> Commit c686078 ("clk: divider: Add round to closest divider") introduced
>> a helper function to check whether given divisor is the best one instead
>> of direct check. However due to int type used instead of unsigned long
>> for passing calculated rates to this function in certain cases an
>> overflow could occur, for example when trying to obtain maximum possible
>> clock rate by calling clk_round_rate(..., UINT_MAX).
>>
>> This patch fixes this issue by changing the type of rate, now and best
>> arguments of the function to unsigned long, which is the type that
>> should be used for clock rates.
>>
>> Signed-off-by: Tomasz Figa
>> ---
>> drivers/clk/clk-divider.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/clk/clk-divider.c b/drivers/clk/clk-divider.c
>> index c572945..e0b360a 100644
>> --- a/drivers/clk/clk-divider.c
>> +++ b/drivers/clk/clk-divider.c
>> @@ -232,7 +232,7 @@ static int _div_round(struct clk_divider *divider,
>> unsigned long parent_rate,
>> }
>>
>> static bool _is_best_div(struct clk_divider *divider,
>> -int rate, int now, int best)
>> +unsigned long rate, unsigned long now, unsigned long best)
>> {
>> if (divider->flags & CLK_DIVIDER_ROUND_CLOSEST)
>> return abs(rate - now) < abs(rate - best);
>>
>
> Ping. It's quite important fix as the issue makes all Exynos boards
> using sdhci-s3c almost unusable.
Any issues with this patch?
Due to this issue, now since almost 3 weeks, all Samsung boards using
sdhci-s3c have been suffering from boot failures on linux-next due to
incorrect clock rates being calculated.
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
Quoting James Bottomley (james.bottom...@hansenpartnership.com): > On Fri, 2014-05-23 at 11:20 +0300, Marian Marinov wrote: > > On 05/20/2014 05:19 PM, Serge Hallyn wrote: > > > Quoting Andy Lutomirski (l...@amacapital.net): > > >> On May 15, 2014 1:26 PM, "Serge E. Hallyn" wrote: > > >>> > > >>> Quoting Richard Weinberger (rich...@nod.at): > > Am 15.05.2014 21:50, schrieb Serge Hallyn: > > > Quoting Richard Weinberger (richard.weinber...@gmail.com): > > >> On Thu, May 15, 2014 at 4:08 PM, Greg Kroah-Hartman > > >> wrote: > > >>> Then don't use a container to build such a thing, or fix the build > > >>> scripts to not do that :) > > >> > > >> I second this. To me it looks like some folks try to (ab)use Linux > > >> containers for purposes where KVM > > >> would much better fit in. Please don't put more complexity into > > >> containers. They are already horrible > > >> complex and error prone. > > > > > > I, naturally, disagree :) The only use case which is inherently not > > > valid for containers is running a > > > kernel. Practically speaking there are other things which likely > > > will never be possible, but if someone > > > offers a way to do something in containers, "you can't do that in > > > containers" is not an apropos response. > > > > > > "That abstraction is wrong" is certainly valid, as when vpids were > > > originally proposed and rejected, > > > resulting in the development of pid namespaces. "We have to work out > > > (x) first" can be valid (and I can > > > think of examples here), assuming it's not just trying to hide behind > > > a catch-22/chicken-egg problem. > > > > > > Finally, saying "containers are complex and error prone" is > > > conflating several large suites of userspace > > > code and many kernel features which support them. Being more precise > > > would, if the argument is valid, lend > > > it a lot more weight. > > > > We (my company) use Linux containers since 2011 in production. First > > LXC, now libvirt-lxc. To understand the > > internals better I also wrote my own userspace to create/start > > containers. There are so many things which can > > hurt you badly. With user namespaces we expose a really big attack > > surface to regular users. I.e. Suddenly a > > user is allowed to mount filesystems. > > >>> > > >>> That is currently not the case. They can mount some virtual > > >>> filesystems and do bind mounts, but cannot mount > > >>> most real filesystems. This keeps us protected (for now) from > > >>> potentially unsafe superblock readers in the > > >>> kernel. > > >>> > > Ask Andy, he found already lots of nasty things... > > >> > > >> I don't think I have anything brilliant to add to this discussion right > > >> now, except possibly: > > >> > > >> ISTM that Linux distributions are, in general, vulnerable to all kinds > > >> of shenanigans that would happen if an > > >> untrusted user can cause a block device to appear. That user doesn't > > >> need permission to mount it > > > > > > Interesting point. This would further suggest that we absolutely must > > > ensure that a loop device which shows up in > > > the container does not also show up in the host. > > > > Can I suggest the usage of the devices cgroup to achieve that? > > Not really ... cgroups impose resource limits, it's namespaces that > impose visibility separations. In theory this can be done with the > device namespace that's been proposed; however, a simpler way is simply > to rm the device node in the host and mknod it in the guest. I don't > really see host visibility as a huge problem: in a shared OS > virtualisation it's not really possible securely to separate the guest > from the host (only vice versa). > > But I really don't think we want to do it this way. Giving a container > the ability to do a mount is too dangerous. What we want to do is > intercept the mount in the host and perform it on behalf of the guest as > host root in the guest's mount namespace. If you do it that way, it That doesn't help the problem of guests being able to provide bad input for (basically fuzz) the in-kernel filesystem code. So apparently I'm suffering a failure of the imagination - what problem exactly does it solve? > doesn't really matter what device actually shows up in the guest, as > long as the host knows what to do when the mount request comes along. > > James > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] staging: comedi: addi_apci_1564: introduce apci1564_private struct
The addi_private struct defined in addi-data/addi_common.h is very bloated
and contains many fields which addi_apci_1564 does not require. In the
interest of eventually removing this driver's dependency on
addi_common.h, we can create a private data struct specifically for
addi_apci_1564 containing only the fields it will actually use.
Signed-off-by: Chase Southwood
Cc: Ian Abbott
Cc: H Hartley Sweeten
---
The idea behind this patch is that it will allow me to rewrite the
apci1564_cos_insn_config() function the same way that Hartley did for
addi_apci_1032.c, using new fields in this private struct. As such, lots
of the fields currently in the struct (all but amcc_iobase, to be precise)
are just temporary, and more fields will be introduced in subsequent
patches as needed. If this is not the best way to proceed then please
let me know and I will change my approach.
.../comedi/drivers/addi-data/hwdrv_apci1564.c | 169 +++--
drivers/staging/comedi/drivers/addi_apci_1564.c| 36 ++---
2 files changed, 106 insertions(+), 99 deletions(-)
diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
index 847cf4c..1846638 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
@@ -49,7 +49,7 @@
#define APCI1564_COUNTER4 3
/*
- * devpriv->i_IobaseAmcc Register Map
+ * devpriv->amcc_iobase Register Map
*/
#define APCI1564_DI_REG0x04
#define APCI1564_DI_INT_MODE1_REG 0x08
@@ -93,6 +93,13 @@
static unsigned int ui_InterruptStatus_1564;
static unsigned int ui_InterruptData, ui_Type;
+struct apci1564_private {
+ unsigned int amcc_iobase; /* base of AMCC I/O registers */
+ unsigned char output_memory_status;
+ unsigned char timer_select_mode;
+ unsigned char mode_select_register;
+};
+
/*
* Configures the digital input Subdevice
*
@@ -106,22 +113,22 @@ static int apci1564_cos_insn_config(struct comedi_device
*dev,
struct comedi_insn *insn,
unsigned int *data)
{
- struct addi_private *devpriv = dev->private;
+ struct apci1564_private *devpriv = dev->private;
/* Set the digital input logic */
if (data[0] == ADDIDATA_ENABLE) {
data[2] = data[2] << 4;
data[3] = data[3] << 4;
- outl(data[2], devpriv->i_IobaseAmcc +
APCI1564_DI_INT_MODE1_REG);
- outl(data[3], devpriv->i_IobaseAmcc +
APCI1564_DI_INT_MODE2_REG);
+ outl(data[2], devpriv->amcc_iobase + APCI1564_DI_INT_MODE1_REG);
+ outl(data[3], devpriv->amcc_iobase + APCI1564_DI_INT_MODE2_REG);
if (data[1] == ADDIDATA_OR)
- outl(0x4, devpriv->i_IobaseAmcc + APCI1564_DI_IRQ_REG);
+ outl(0x4, devpriv->amcc_iobase + APCI1564_DI_IRQ_REG);
else
- outl(0x6, devpriv->i_IobaseAmcc + APCI1564_DI_IRQ_REG);
+ outl(0x6, devpriv->amcc_iobase + APCI1564_DI_IRQ_REG);
} else {
- outl(0x0, devpriv->i_IobaseAmcc + APCI1564_DI_INT_MODE1_REG);
- outl(0x0, devpriv->i_IobaseAmcc + APCI1564_DI_INT_MODE2_REG);
- outl(0x0, devpriv->i_IobaseAmcc + APCI1564_DI_IRQ_REG);
+ outl(0x0, devpriv->amcc_iobase + APCI1564_DI_INT_MODE1_REG);
+ outl(0x0, devpriv->amcc_iobase + APCI1564_DI_INT_MODE2_REG);
+ outl(0x0, devpriv->amcc_iobase + APCI1564_DI_IRQ_REG);
}
return insn->n;
@@ -138,7 +145,7 @@ static int apci1564_do_config(struct comedi_device *dev,
struct comedi_insn *insn,
unsigned int *data)
{
- struct addi_private *devpriv = dev->private;
+ struct apci1564_private *devpriv = dev->private;
unsigned int ul_Command = 0;
if ((data[0] != 0) && (data[0] != 1)) {
@@ -148,9 +155,9 @@ static int apci1564_do_config(struct comedi_device *dev,
}
if (data[0])
- devpriv->b_OutputMemoryStatus = ADDIDATA_ENABLE;
+ devpriv->output_memory_status = ADDIDATA_ENABLE;
else
- devpriv->b_OutputMemoryStatus = ADDIDATA_DISABLE;
+ devpriv->output_memory_status = ADDIDATA_DISABLE;
if (data[1] == ADDIDATA_ENABLE)
ul_Command = ul_Command | 0x1;
@@ -162,8 +169,8 @@ static int apci1564_do_config(struct comedi_device *dev,
else
ul_Command = ul_Command & 0xFFFD;
- outl(ul_Command, devpriv->i_IobaseAmcc + APCI1564_DO_INT_CTRL_REG);
- ui_InterruptData = inl(devpriv->i_IobaseAmcc +
APCI1564_DO_INT_CTRL_REG);
+ outl(ul_Command, devpriv->amcc_iobase +
[PATCH 2/3] staging: comedi: addi_apci_1564: remove send_sig() use
The addi-data drivers use send_sig() to let the user know when an
interrupt has occurred. The "standard" way to do this in the comedi
subsystem is to have a subdevice that supports asynchronous commands
and use comedi_event() to signal the user.
Remove the send_sig() usage in this driver.
Signed-off-by: Chase Southwood
Cc: Ian Abbott
Cc: H Hartley Sweeten
---
.../comedi/drivers/addi-data/hwdrv_apci1564.c | 23 --
1 file changed, 23 deletions(-)
diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
index a38ccf9..847cf4c 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
@@ -108,8 +108,6 @@ static int apci1564_cos_insn_config(struct comedi_device
*dev,
{
struct addi_private *devpriv = dev->private;
- devpriv->tsk_Current = current;
-
/* Set the digital input logic */
if (data[0] == ADDIDATA_ENABLE) {
data[2] = data[2] << 4;
@@ -166,7 +164,6 @@ static int apci1564_do_config(struct comedi_device *dev,
outl(ul_Command, devpriv->i_IobaseAmcc + APCI1564_DO_INT_CTRL_REG);
ui_InterruptData = inl(devpriv->i_IobaseAmcc +
APCI1564_DO_INT_CTRL_REG);
- devpriv->tsk_Current = current;
return insn->n;
}
@@ -189,7 +186,6 @@ static int apci1564_timer_config(struct comedi_device *dev,
struct addi_private *devpriv = dev->private;
unsigned int ul_Command1 = 0;
- devpriv->tsk_Current = current;
if (data[0] == ADDIDATA_WATCHDOG) {
devpriv->b_TimerSelectMode = ADDIDATA_WATCHDOG;
@@ -436,8 +432,6 @@ static void apci1564_interrupt(int irq, void *d)
ui_InterruptStatus_1564 =
inl(devpriv->i_IobaseAmcc + APCI1564_DI_INT_STATUS_REG);
ui_InterruptStatus_1564 = ui_InterruptStatus_1564 & 0X0000;
- /* send signal to the sample */
- send_sig(SIGIO, devpriv->tsk_Current, 0);
/* enable the interrupt */
outl(ui_DI, devpriv->i_IobaseAmcc + APCI1564_DI_IRQ_REG);
return;
@@ -451,8 +445,6 @@ static void apci1564_interrupt(int irq, void *d)
/* Disable the Interrupt */
outl(0x0, devpriv->i_IobaseAmcc + APCI1564_DO_INT_CTRL_REG);
- /* Sends signal to user space */
- send_sig(SIGIO, devpriv->tsk_Current, 0);
}
if (ui_Timer == 1) {
@@ -463,9 +455,6 @@ static void apci1564_interrupt(int irq, void *d)
ul_Command2 = inl(devpriv->i_IobaseAmcc +
APCI1564_TIMER_CTRL_REG);
outl(0x0, devpriv->i_IobaseAmcc +
APCI1564_TIMER_CTRL_REG);
- /* Send a signal to from kernel to user space */
- send_sig(SIGIO, devpriv->tsk_Current, 0);
-
/* Enable Timer Interrupt */
outl(ul_Command2, devpriv->i_IobaseAmcc +
APCI1564_TIMER_CTRL_REG);
@@ -482,9 +471,6 @@ static void apci1564_interrupt(int irq, void *d)
outl(0x0,
dev->iobase +
APCI1564_TCW_CTRL_REG(APCI1564_COUNTER1));
- /* Send a signal to from kernel to user space */
- send_sig(SIGIO, devpriv->tsk_Current, 0);
-
/* Enable Counter Interrupt */
outl(ul_Command2,
dev->iobase +
APCI1564_TCW_CTRL_REG(APCI1564_COUNTER1));
@@ -501,9 +487,6 @@ static void apci1564_interrupt(int irq, void *d)
outl(0x0,
dev->iobase +
APCI1564_TCW_CTRL_REG(APCI1564_COUNTER2));
- /* Send a signal to from kernel to user space */
- send_sig(SIGIO, devpriv->tsk_Current, 0);
-
/* Enable Counter Interrupt */
outl(ul_Command2,
dev->iobase +
APCI1564_TCW_CTRL_REG(APCI1564_COUNTER2));
@@ -520,9 +503,6 @@ static void apci1564_interrupt(int irq, void *d)
outl(0x0,
dev->iobase +
APCI1564_TCW_CTRL_REG(APCI1564_COUNTER3));
- /* Send a signal to from kernel to user space */
- send_sig(SIGIO, devpriv->tsk_Current, 0);
-
/* Enable Counter Interrupt */
outl(ul_Command2,
dev->iobase +
APCI1564_TCW_CTRL_REG(APCI1564_COUNTER3));
@@ -539,9 +519,6 @@ static void apci1564_interrupt(int irq, void *d)
outl(0x0,
dev->iobase +
APCI1564_TCW_CTRL_REG(APCI1564_COUNTER4));
- /* Send a signal to from kernel to user space */
- send_sig(SIGIO, devpriv->tsk_Current, 0);
-
[PATCH 1/3] staging: comedi: addi_apci_1564: add a subdevice for Change-of-State interrupt support
This board supports an interrupt that can be generated by an AND/OR
combination of 16 of the input channels.
Create a separate subdevice to handle this interrupt.
In doing this, this patch moves the apci1564_di_config() operation from
the digital input subdevice to this new subdevice, and also renames it to
make it more apparent that it is the config operation for the COS interrupt.
Signed-off-by: Chase Southwood
Cc: Ian Abbott
Cc: H Hartley Sweeten
---
.../staging/comedi/drivers/addi-data/hwdrv_apci1564.c | 8
drivers/staging/comedi/drivers/addi_apci_1564.c| 18 --
2 files changed, 20 insertions(+), 6 deletions(-)
diff --git a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
index 0ba5385..a38ccf9 100644
--- a/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
+++ b/drivers/staging/comedi/drivers/addi-data/hwdrv_apci1564.c
@@ -101,10 +101,10 @@ static unsigned int ui_InterruptData, ui_Type;
* data[2] Interrupt mask for the mode 1
* data[3] Interrupt mask for the mode 2
*/
-static int apci1564_di_config(struct comedi_device *dev,
- struct comedi_subdevice *s,
- struct comedi_insn *insn,
- unsigned int *data)
+static int apci1564_cos_insn_config(struct comedi_device *dev,
+ struct comedi_subdevice *s,
+ struct comedi_insn *insn,
+ unsigned int *data)
{
struct addi_private *devpriv = dev->private;
diff --git a/drivers/staging/comedi/drivers/addi_apci_1564.c
b/drivers/staging/comedi/drivers/addi_apci_1564.c
index 13d9962..6af1e4c 100644
--- a/drivers/staging/comedi/drivers/addi_apci_1564.c
+++ b/drivers/staging/comedi/drivers/addi_apci_1564.c
@@ -105,7 +105,7 @@ static int apci1564_auto_attach(struct comedi_device *dev,
dev->irq = pcidev->irq;
}
- ret = comedi_alloc_subdevices(dev, 3);
+ ret = comedi_alloc_subdevices(dev, 4);
if (ret)
return ret;
@@ -117,7 +117,6 @@ static int apci1564_auto_attach(struct comedi_device *dev,
s->maxdata = 1;
s->len_chanlist = 32;
s->range_table = _digital;
- s->insn_config = apci1564_di_config;
s->insn_bits = apci1564_di_insn_bits;
/* Allocate and Initialise DO Subdevice Structures */
@@ -144,6 +143,21 @@ static int apci1564_auto_attach(struct comedi_device *dev,
s->insn_read = apci1564_timer_read;
s->insn_config = apci1564_timer_config;
+ /* Change-Of-State (COS) interrupt subdevice */
+ s = >subdevices[3];
+ if (dev->irq) {
+ dev->read_subdev = s;
+ s->type = COMEDI_SUBD_DI;
+ s->subdev_flags = SDF_READABLE | SDF_CMD_READ;
+ s->n_chan = 1;
+ s->maxdata = 1;
+ s->len_chanlist = 1;
+ s->range_table = _digital;
+ s->insn_config = apci1564_cos_insn_config;
+ } else {
+ s->type = COMEDI_SUBD_UNUSED;
+ }
+
return 0;
}
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] staging: comedi: addi_apci_1564: prepare for adding Change-of-State interrupt support
This patchset adds the required subdevice for supporting DI COS interrupts, as well as introducing a driver-specific private data struct that will make the COS interrupt operations much more straightforward and clean. Chase Southwood (3): staging: comedi: addi_apci_1564: add a subdevice for Change-of-State interrupt support staging: comedi: addi_apci_1564: remove send_sig() use staging: comedi: addi_apci_1564: introduce apci1564_private struct .../comedi/drivers/addi-data/hwdrv_apci1564.c | 200 ++--- drivers/staging/comedi/drivers/addi_apci_1564.c| 54 +++--- 2 files changed, 126 insertions(+), 128 deletions(-) -- 1.9.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] lib/debugobjects.c: code clean-up
On Sat, May 24, 2014 at 03:08:06PM +0200, Fabian Frederick wrote: > Fix some checkpatch warnings. > > Cc: Josh Triplett > Cc: Andrew Morton > Signed-off-by: Fabian Frederick Some of these make sense, one of them does not. Comments below. Also, please explicitly note the checkpatch warnings you fixed, not just "Fix some checkpatch warnings.". > --- a/lib/debugobjects.c > +++ b/lib/debugobjects.c [...] > @@ -415,7 +415,8 @@ int debug_object_activate(void *addr, struct > debug_obj_descr *descr) > debug_print_object(obj, "activate"); > state = obj->state; > raw_spin_unlock_irqrestore(>lock, flags); > - ret = debug_object_fixup(descr->fixup_activate, addr, > state); > + ret = debug_object_fixup(descr->fixup_activate, > + addr, state); This does not seem like a worthwhile improvement. Please don't blindly listen to checkpatch, especially regarding line lengths. - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] lib/debugobjects.c: move __initdata after name
On Sat, May 24, 2014 at 03:07:19PM +0200, Fabian Frederick wrote:
> Cc: Josh Triplett
> Cc: Andrew Morton
> Signed-off-by: Fabian Frederick
No, don't make this change. A quick "git grep __initdata" shows that to
the extent it has a consistent placement, it's either right after the
type ("static some_type __initdata varname") or right after the storage
class ("static __initdata some_type varname"). Other similar qualifiers
follow the same pattern.
> lib/debugobjects.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/lib/debugobjects.c b/lib/debugobjects.c
> index b628247..437a6b4 100644
> --- a/lib/debugobjects.c
> +++ b/lib/debugobjects.c
> @@ -791,7 +791,7 @@ struct self_test {
> unsigned long dummy2[3];
> };
>
> -static __initdata struct debug_obj_descr descr_type_test;
> +static struct debug_obj_descr descr_type_test __initdata;
>
> /*
> * fixup_init is called when:
> @@ -915,7 +915,7 @@ out:
> return res;
> }
>
> -static __initdata struct debug_obj_descr descr_type_test = {
> +static struct debug_obj_descr descr_type_test __initdata = {
> .name = "selftest",
> .fixup_init = fixup_init,
> .fixup_activate = fixup_activate,
> @@ -923,7 +923,7 @@ static __initdata struct debug_obj_descr descr_type_test
> = {
> .fixup_free = fixup_free,
> };
>
> -static __initdata struct self_test obj = { .static_init = 0 };
> +static struct self_test obj __initdata = { .static_init = 0 };
>
> static void __init debug_objects_selftest(void)
> {
> --
> 1.8.4.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] lib/debugobjects.c: add pr_fmt to logging
On Sat, May 24, 2014 at 03:06:55PM +0200, Fabian Frederick wrote:
> Add ODEBUG: prefix to pr_fmt
>
> Cc: Josh Triplett
> Cc: Andrew Morton
> Signed-off-by: Fabian Frederick
Reviewed-by: Josh Triplett
> lib/debugobjects.c | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/lib/debugobjects.c b/lib/debugobjects.c
> index ea4c737..b628247 100644
> --- a/lib/debugobjects.c
> +++ b/lib/debugobjects.c
> @@ -7,6 +7,9 @@
> *
> * For licencing details see kernel-base/COPYING
> */
> +
> +#define pr_fmt(fmt) "ODEBUG: " fmt
> +
> #include
> #include
> #include
> @@ -218,7 +221,7 @@ static void debug_objects_oom(void)
> unsigned long flags;
> int i;
>
> - pr_warn("ODEBUG: Out of memory. ODEBUG disabled\n");
> + pr_warn("Out of memory. ODEBUG disabled\n");
>
> for (i = 0; i < ODEBUG_HASH_SIZE; i++, db++) {
> raw_spin_lock_irqsave(>lock, flags);
> @@ -292,9 +295,9 @@ static void debug_object_is_on_stack(void *addr, int
> onstack)
>
> limit++;
> if (is_on_stack)
> - pr_warn("ODEBUG: object is on stack, but not annotated\n");
> + pr_warn("object is on stack, but not annotated\n");
> else
> - pr_warn("ODEBUG: object is not on stack, but annotated\n");
> + pr_warn("object is not on stack, but annotated\n");
> WARN_ON(1);
> }
>
> @@ -983,7 +986,7 @@ static void __init debug_objects_selftest(void)
> if (check_results(, ODEBUG_STATE_NONE, ++fixups, ++warnings))
> goto out;
> #endif
> - pr_info("ODEBUG: selftest passed\n");
> + pr_info("selftest passed\n");
>
> out:
> debug_objects_fixups = oldfixups;
> @@ -1088,7 +1091,7 @@ void __init debug_objects_mem_init(void)
> debug_objects_enabled = 0;
> if (obj_cache)
> kmem_cache_destroy(obj_cache);
> - pr_warn("ODEBUG: out of memory.\n");
> + pr_warn("out of memory.\n");
> } else
> debug_objects_selftest();
> }
> --
> 1.8.4.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] lib/debugobjects.c: convert printk to pr_foo()
On Sat, May 24, 2014 at 03:06:08PM +0200, Fabian Frederick wrote:
> Convert all except KERN_DEBUG
Why not KERN_DEBUG?
> Cc: Josh Triplett
> Cc: Andrew Morton
> Signed-off-by: Fabian Frederick
Reviewed-by: Josh Triplett
> lib/debugobjects.c | 12 +---
> 1 file changed, 5 insertions(+), 7 deletions(-)
>
> diff --git a/lib/debugobjects.c b/lib/debugobjects.c
> index e0731c3..ea4c737 100644
> --- a/lib/debugobjects.c
> +++ b/lib/debugobjects.c
> @@ -218,7 +218,7 @@ static void debug_objects_oom(void)
> unsigned long flags;
> int i;
>
> - printk(KERN_WARNING "ODEBUG: Out of memory. ODEBUG disabled\n");
> + pr_warn("ODEBUG: Out of memory. ODEBUG disabled\n");
>
> for (i = 0; i < ODEBUG_HASH_SIZE; i++, db++) {
> raw_spin_lock_irqsave(>lock, flags);
> @@ -292,11 +292,9 @@ static void debug_object_is_on_stack(void *addr, int
> onstack)
>
> limit++;
> if (is_on_stack)
> - printk(KERN_WARNING
> -"ODEBUG: object is on stack, but not annotated\n");
> + pr_warn("ODEBUG: object is on stack, but not annotated\n");
> else
> - printk(KERN_WARNING
> -"ODEBUG: object is not on stack, but annotated\n");
> + pr_warn("ODEBUG: object is not on stack, but annotated\n");
> WARN_ON(1);
> }
>
> @@ -985,7 +983,7 @@ static void __init debug_objects_selftest(void)
> if (check_results(, ODEBUG_STATE_NONE, ++fixups, ++warnings))
> goto out;
> #endif
> - printk(KERN_INFO "ODEBUG: selftest passed\n");
> + pr_info("ODEBUG: selftest passed\n");
>
> out:
> debug_objects_fixups = oldfixups;
> @@ -1090,7 +1088,7 @@ void __init debug_objects_mem_init(void)
> debug_objects_enabled = 0;
> if (obj_cache)
> kmem_cache_destroy(obj_cache);
> - printk(KERN_WARNING "ODEBUG: out of memory.\n");
> + pr_warn("ODEBUG: out of memory.\n");
> } else
> debug_objects_selftest();
> }
> --
> 1.8.4.5
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[usb-dev] [probably a bug] GINZZU GR-126B cardreader misbehavior.
Hello, dear Developers. Recently, I've got this device: http://ginzzu.com/rus_level5_tab1.php?lang=NAME_ENG=520=-1=51_id=-10 It is an internal usb-cardreader. lsusb shows it as Bus 003 Device 004: ID 14cd:168a Super Top A manufacturer claims that it works in linux systems but that's not quite so. It works incorrectly. You should manually mount /dev/sdb under root to be able to read inserted card. Or, you should unplug it before inserting a card after that insert a card then plug it again. Then inserted card is recognized and mounted. My environment: Debian/sid Linux servant 3.14-1-amd64 #1 SMP Debian 3.14.4-1 (2014-05-13) x86_64 GNU/Linux KDE Desktop What kind of info may help to determine what is a cause of such manner? All other usb-devices work well (bluetooth dongle, web-cam, wireless mouse, usb-sticks). For more info: lsusb default output Bus 004 Device 004: ID 04d9:1605 Holtek Semiconductor, Inc. Bus 004 Device 003: ID 0c45:62e0 Microdia MSI Starcam Racer Bus 004 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 004 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 004: ID 14cd:168a Super Top Bus 003 Device 003: ID 09da:054f A4 Tech Co., Ltd Bus 003 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub lspci default output 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor DRAM Controller (rev 09) 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09) 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09) 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) 00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04) 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) 00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04) 00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 (rev c4) 00:1c.4 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 5 (rev c4) 00:1c.5 PCI bridge: Intel Corporation 82801 PCI Bridge (rev c4) 00:1c.6 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 7 (rev c4) 00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) 00:1f.0 ISA bridge: Intel Corporation H77 Express Chipset LPC Controller (rev 04) 00:1f.2 SATA controller: Intel Corporation 7 Series/C210 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04) 00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04) 03:00.0 Ethernet controller: Qualcomm Atheros AR8161 Gigabit Ethernet (rev 10) 04:00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge (rev 03) 06:00.0 Network controller: Qualcomm Atheros AR9485 Wireless Network Adapter (rev 01) -- Sincerely Yours, Sergey Sarbash. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: imx: introduce function imx_free_mx3_camera
Hello, On Sat, May 24, 2014 at 01:05:00PM -0700, Greg Kroah-Hartman wrote: > Please feel free to break it up as asked for and I'll be glad to > consider it then. ack Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sparc64 WARNING: at mm/mmap.c:2757 exit_mmap+0x13c/0x160()
From: mr...@linux.ee Date: Sat, 24 May 2014 23:02:28 +0300 (EEST) > This is todays fresh git with 3.15.0-rc6-00190-g1ee1cea on V210, THP > enabled & always on. Got this and a segfault on apt-spawned xz. Thanks a lot for the report. I've been bogged down with other things but I will come back to this stuff soon. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH linux-next] DRM: Armada: update dma_buf_export use
The dma_buf_export function was updated in commit 4bcec44ffaf9 'dma-buf: use
reservation objects' to take a reservation object parameter; update Armada
export method accordingly.
This fixes the following compilation error:
drivers/gpu/drm/armada/armada_gem.c: In function ‘armada_gem_prime_export’:
drivers/gpu/drm/armada/armada_gem.c:544:16: error: macro "dma_buf_export"
requires 5 arguments, but only 4 given
Signed-off-by: Vincent Stehlé
Cc: Russell King
Cc: David Airlie
Cc: Maarten Lankhorst
Cc: Sumit Semwal
---
Hi,
This can be seen with e.g. linux next-20140523 and arm allmodconfig.
Best regards,
V.
drivers/gpu/drm/armada/armada_gem.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/armada/armada_gem.c
b/drivers/gpu/drm/armada/armada_gem.c
index 887816f..7adb0c3 100644
--- a/drivers/gpu/drm/armada/armada_gem.c
+++ b/drivers/gpu/drm/armada/armada_gem.c
@@ -541,7 +541,7 @@ armada_gem_prime_export(struct drm_device *dev, struct
drm_gem_object *obj,
int flags)
{
return dma_buf_export(obj, _gem_prime_dmabuf_ops, obj->size,
- O_RDWR);
+ O_RDWR, NULL);
}
struct drm_gem_object *
--
2.0.0.rc2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: cdc-acm: fix broken runtime suspend
On Sat, May 24, 2014 at 12:59:07PM -0700, Greg Kroah-Hartman wrote: > On Sat, May 24, 2014 at 04:42:42PM +0200, Johan Hovold wrote: > > Could you please discard this one for now? I've found a couple of more > > PM related problems and I'll submit a slight update of this one as part > > of a larger series of fixes instead. > > I think it's already in my tree, right? I don't see it in my to-apply > queue. Can you send me the git id to revert, or just a patch that > reverts it? No, you haven't applied it yet, so that's good. I should be able to send the complete series in a few days. Thanks, Johan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: imx: introduce function imx_free_mx3_camera
On Sat, May 24, 2014 at 05:22:00PM +0200, Emil Goode wrote: > Hello Uwe and Greg, > > > You'd do a better deed if you picked up > > http://thread.gmane.org/gmane.linux.kernel/1613364/focus=1635995 > > Since there is nothing wrong with the last version of the patch in > the above thread, I feel strange about picking it up and just splitting > it into two patches. However it would be good to have it applied. > > I think the reason why the author didn't resend is that the object file > and data structure layout information in the changelog depend on the > changes to both .name and .dma_mask and by splitting the patch this > information would not apply to any one of the resulting two patches. > > Perhaps keeping this information in the changelog is a good reason for > applying the patch as it is? If you read the thread, I explained why I didn't want to take the patch as-is. Please feel free to break it up as asked for and I'll be glad to consider it then. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sparc64 WARNING: at mm/mmap.c:2757 exit_mmap+0x13c/0x160()
This is todays fresh git with 3.15.0-rc6-00190-g1ee1cea on V210, THP enabled & always on. Got this and a segfault on apt-spawned xz. [ 142.599575] [ cut here ] [ 142.660349] WARNING: CPU: 1 PID: 2237 at mm/mmap.c:2741 exit_mmap+0x140/0x160() [ 142.756483] Modules linked in: ipv6 tg3 hwmon ptp pps_core [ 142.830269] CPU: 1 PID: 2237 Comm: aptitude Not tainted 3.15.0-rc6-00190-g1ee1cea #93 [ 142.933226] Call Trace: [ 142.965358] [0045a12c] warn_slowpath_common+0x4c/0x80 [ 143.042074] [004e7a40] exit_mmap+0x140/0x160 [ 143.108410] [004586a0] mmput.part.60+0x20/0xe0 [ 143.177030] [0045af3c] exit_mm+0x11c/0x180 [ 143.241071] [0045c920] do_exit+0x240/0x340 [ 143.305134] [0045cb48] do_group_exit+0x28/0xc0 [ 143.373753] [00468ac8] get_signal_to_deliver+0x1c8/0x3a0 [ 143.453819] [00449334] do_signal32+0x14/0x220 [ 143.521292] [0042d0e0] do_signal+0x2c0/0x520 [ 143.587624] [0042db40] do_notify_resume+0x40/0x60 [ 143.659683] [00404b04] __handle_signal+0xc/0x2c [ 143.729448] ---[ end trace b34008751438e7e6 ]--- [ 143.790182] BUG: Bad rss-counter state mm:fc000d9d3660 idx:1 val:1 -- Meelis Roos (mr...@linux.ee) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] dt: Add DT bindings documentation for SUNXI Security System
On Saturday, May 24, 2014 at 09:51:59 PM, Tomasz Figa wrote: [...] > >>> Why sun7i-a20 ? Is the crypto unit different in other sunxi chips ? Can > >>> that not be described by DT props ? > >> > >> A widely used convention is to define compatible strings after first > >> SoCs on which particular IP blocks appear. It is quite common among IP > >> blocks for which there is no well defined versioning scheme. > > > > Well yeah, that's fine. But in this case, "sun7i" is the entire group of > > CPUs manufactured by AW. I find that information redundant, the > > "allwinner,a20- crypto" would suffice. But I wonder if that IP block > > might have appeared even earlier ? Or if it is CPU family specific, thus > > "allwinner,sun7i-crypto" would be a better string ? > > I'm not aware of Allwinner naming schemes too much, so please correct me > if I'm wrong, but if A20 implies sun7i, then "allwinner,a20-crypto" > would be better indeed. True. > Whether it was really the first SoC is another thing. Obviously this > needs to be checked, although it isn't really that important. For this > particular naming scheme you need to specify all the SoCs for which > given compatible string can be used for this IP anyway, because there is > usually no other source of information about this available (except > directly comparing two datasheets...). Better get the DT stuff correctly right from the start. That's why I'm asking what chips contains the IP block, so we can guess the right name. Best regards, Marek Vasut -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] USB: cdc-acm: fix broken runtime suspend
On Sat, May 24, 2014 at 04:42:42PM +0200, Johan Hovold wrote: > On Mon, Apr 14, 2014 at 09:58:12PM +0200, Johan Hovold wrote: > > The current ACM runtime-suspend implementation is broken in several > > ways: > > > > Firstly, it buffers only the first write request being made while > > suspended -- any further writes are silently dropped. > > > > Secondly, writes being dropped also leak write urbs, which are never > > reclaimed (until the device is unbound). > > > > Thirdly, even the single buffered write is not cleared at shutdown > > (which may happen before the device is resumed), something which can > > lead to another urb leak as well as a PM usage-counter leak. > > > > Fix this by implementing a delayed-write queue using urb anchors and > > making sure to discard the queue properly at shutdown. > > > > Reported-by: Xiao Jin > > Signed-off-by: Johan Hovold > > Greg, > > I understand yoǘ're on your way home from Japan and are getting ready to > work through the 3.16 patch queue. > > Could you please discard this one for now? I've found a couple of more > PM related problems and I'll submit a slight update of this one as part > of a larger series of fixes instead. I think it's already in my tree, right? I don't see it in my to-apply queue. Can you send me the git id to revert, or just a patch that reverts it? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] dt: Add DT bindings documentation for SUNXI Security System
On 24.05.2014 21:43, Marek Vasut wrote: > On Saturday, May 24, 2014 at 09:20:03 PM, Tomasz Figa wrote: >> Hi Marek, >> >> On 24.05.2014 13:21, Marek Vasut wrote: >>> On Thursday, May 22, 2014 at 05:09:54 PM, LABBE Corentin wrote: >>> >>> Missing commit message. Please fix this and send a V2. >>> Signed-off-by: LABBE Corentin --- Documentation/devicetree/bindings/crypto/sunxi-ss.txt | 9 + 1 file changed, 9 insertions(+) create mode 100644 Documentation/devicetree/bindings/crypto/sunxi-ss.txt diff --git a/Documentation/devicetree/bindings/crypto/sunxi-ss.txt b/Documentation/devicetree/bindings/crypto/sunxi-ss.txt new file mode 100644 index 000..356563b --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/sunxi-ss.txt @@ -0,0 +1,9 @@ +* Allwinner Security System found on A20 SoC + +Required properties: +- compatible : Should be "allwinner,sun7i-a20-crypto". >>> >>> Why sun7i-a20 ? Is the crypto unit different in other sunxi chips ? Can >>> that not be described by DT props ? >> >> A widely used convention is to define compatible strings after first >> SoCs on which particular IP blocks appear. It is quite common among IP >> blocks for which there is no well defined versioning scheme. > > Well yeah, that's fine. But in this case, "sun7i" is the entire group of CPUs > manufactured by AW. I find that information redundant, the "allwinner,a20- > crypto" would suffice. But I wonder if that IP block might have appeared even > earlier ? Or if it is CPU family specific, thus "allwinner,sun7i-crypto" > would > be a better string ? I'm not aware of Allwinner naming schemes too much, so please correct me if I'm wrong, but if A20 implies sun7i, then "allwinner,a20-crypto" would be better indeed. Whether it was really the first SoC is another thing. Obviously this needs to be checked, although it isn't really that important. For this particular naming scheme you need to specify all the SoCs for which given compatible string can be used for this IP anyway, because there is usually no other source of information about this available (except directly comparing two datasheets...). Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] dt: Add DT bindings documentation for SUNXI Security System
On Saturday, May 24, 2014 at 09:20:03 PM, Tomasz Figa wrote: > Hi Marek, > > On 24.05.2014 13:21, Marek Vasut wrote: > > On Thursday, May 22, 2014 at 05:09:54 PM, LABBE Corentin wrote: > > > > Missing commit message. Please fix this and send a V2. > > > >> Signed-off-by: LABBE Corentin > >> --- > >> > >> Documentation/devicetree/bindings/crypto/sunxi-ss.txt | 9 + > >> 1 file changed, 9 insertions(+) > >> create mode 100644 > >> Documentation/devicetree/bindings/crypto/sunxi-ss.txt > >> > >> diff --git a/Documentation/devicetree/bindings/crypto/sunxi-ss.txt > >> b/Documentation/devicetree/bindings/crypto/sunxi-ss.txt new file mode > >> 100644 > >> index 000..356563b > >> --- /dev/null > >> +++ b/Documentation/devicetree/bindings/crypto/sunxi-ss.txt > >> @@ -0,0 +1,9 @@ > >> +* Allwinner Security System found on A20 SoC > >> + > >> +Required properties: > >> +- compatible : Should be "allwinner,sun7i-a20-crypto". > > > > Why sun7i-a20 ? Is the crypto unit different in other sunxi chips ? Can > > that not be described by DT props ? > > A widely used convention is to define compatible strings after first > SoCs on which particular IP blocks appear. It is quite common among IP > blocks for which there is no well defined versioning scheme. Well yeah, that's fine. But in this case, "sun7i" is the entire group of CPUs manufactured by AW. I find that information redundant, the "allwinner,a20- crypto" would suffice. But I wonder if that IP block might have appeared even earlier ? Or if it is CPU family specific, thus "allwinner,sun7i-crypto" would be a better string ? Best regards, Marek Vasut -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] dt: Add DT bindings documentation for SUNXI Security System
Hi Marek, On 24.05.2014 13:21, Marek Vasut wrote: > On Thursday, May 22, 2014 at 05:09:54 PM, LABBE Corentin wrote: > > Missing commit message. Please fix this and send a V2. > >> Signed-off-by: LABBE Corentin >> --- >> Documentation/devicetree/bindings/crypto/sunxi-ss.txt | 9 + >> 1 file changed, 9 insertions(+) >> create mode 100644 Documentation/devicetree/bindings/crypto/sunxi-ss.txt >> >> diff --git a/Documentation/devicetree/bindings/crypto/sunxi-ss.txt >> b/Documentation/devicetree/bindings/crypto/sunxi-ss.txt new file mode >> 100644 >> index 000..356563b >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/crypto/sunxi-ss.txt >> @@ -0,0 +1,9 @@ >> +* Allwinner Security System found on A20 SoC >> + >> +Required properties: >> +- compatible : Should be "allwinner,sun7i-a20-crypto". > > Why sun7i-a20 ? Is the crypto unit different in other sunxi chips ? Can that > not > be described by DT props ? A widely used convention is to define compatible strings after first SoCs on which particular IP blocks appear. It is quite common among IP blocks for which there is no well defined versioning scheme. Best regards, Tomasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] msi3103: Use time_before_eq()
On Sat, 2014-05-24 at 20:47 +0200, Manuel Schölling wrote:
> To be future-proof and for better readability the time comparisons are
> modified to use time_before_eq() instead of plain, error-prone math.
A couple of unrelated, trivial notes: (repeated a few times)
> diff --git a/drivers/staging/media/msi3101/sdr-msi3101.c
> b/drivers/staging/media/msi3101/sdr-msi3101.c
[]
> @@ -208,7 +208,7 @@ static int msi3101_convert_stream_504(struct
> msi3101_state *s, u8 *dst,
> }
>
> /* calculate samping rate and output it in 10 seconds intervals */
s/samping/sampling/
> - if ((s->jiffies_next + msecs_to_jiffies(1)) <= jiffies) {
> + if (time_before_eq(s->jiffies_next + 10 * HZ, jiffies)) {
> unsigned long jiffies_now = jiffies;
> unsigned long msecs = jiffies_to_msecs(jiffies_now) -
> jiffies_to_msecs(s->jiffies_next);
Perhaps better to subtract then convert
instead of convert twice then subtract.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/6] mm/zbud: change zbud_alloc size type to size_t
Change the type of the zbud_alloc() size param from unsigned int
to size_t.
Technically, this should not make any difference, as the zbud
implementation already restricts the size to well within either
type's limits; but as zsmalloc (and kmalloc) use size_t, and
zpool will use size_t, this brings the size parameter type
in line with zsmalloc/zpool.
Signed-off-by: Dan Streetman
Acked-by: Seth Jennings
Cc: Weijie Yang
---
No change since v1 : https://lkml.org/lkml/2014/5/7/757
include/linux/zbud.h | 2 +-
mm/zbud.c| 5 ++---
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/include/linux/zbud.h b/include/linux/zbud.h
index 0b2534e..1e9cb57 100644
--- a/include/linux/zbud.h
+++ b/include/linux/zbud.h
@@ -11,7 +11,7 @@ struct zbud_ops {
struct zbud_pool *zbud_create_pool(gfp_t gfp, struct zbud_ops *ops);
void zbud_destroy_pool(struct zbud_pool *pool);
-int zbud_alloc(struct zbud_pool *pool, unsigned int size,
+int zbud_alloc(struct zbud_pool *pool, size_t size,
unsigned long *handle);
void zbud_free(struct zbud_pool *pool, unsigned long handle);
int zbud_reclaim_page(struct zbud_pool *pool, unsigned int retries);
diff --git a/mm/zbud.c b/mm/zbud.c
index 847c01c..dd13665 100644
--- a/mm/zbud.c
+++ b/mm/zbud.c
@@ -123,7 +123,7 @@ enum buddy {
};
/* Converts an allocation size in bytes to size in zbud chunks */
-static int size_to_chunks(int size)
+static int size_to_chunks(size_t size)
{
return (size + CHUNK_SIZE - 1) >> CHUNK_SHIFT;
}
@@ -250,8 +250,7 @@ void zbud_destroy_pool(struct zbud_pool *pool)
* -EINVAL if the @size is 0, or -ENOMEM if the pool was unable to
* allocate a new page.
*/
-int zbud_alloc(struct zbud_pool *pool, unsigned int size,
- unsigned long *handle)
+int zbud_alloc(struct zbud_pool *pool, size_t size, unsigned long *handle)
{
int chunks, i, freechunks;
struct zbud_header *zhdr = NULL;
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/6] mm/zpool: zbud/zsmalloc implement zpool
Update zbud and zsmalloc to implement the zpool api.
Signed-off-by: Dan Streetman
Cc: Seth Jennings
Cc: Minchan Kim
Cc: Nitin Gupta
Cc: Weijie Yang
---
New for this patch set.
mm/zbud.c | 78
mm/zsmalloc.c | 81 +++
2 files changed, 159 insertions(+)
diff --git a/mm/zbud.c b/mm/zbud.c
index dd13665..8a72cb1 100644
--- a/mm/zbud.c
+++ b/mm/zbud.c
@@ -51,6 +51,7 @@
#include
#include
#include
+#include
/*
* Structures
@@ -114,6 +115,74 @@ struct zbud_header {
};
/*
+ * zpool
+ /
+
+#ifdef CONFIG_ZPOOL
+
+static int zbud_zpool_evict(struct zbud_pool *pool, unsigned long handle)
+{
+ return zpool_evict(pool, handle);
+}
+
+static struct zbud_ops zbud_zpool_ops = {
+ .evict =zbud_zpool_evict
+};
+
+static void *zbud_zpool_create(gfp_t gfp, struct zpool_ops *zpool_ops)
+{
+ return zbud_create_pool(gfp, _zpool_ops);
+}
+
+void zbud_zpool_destroy(void *pool)
+{
+ zbud_destroy_pool(pool);
+}
+
+int zbud_zpool_malloc(void *pool, size_t size, unsigned long *handle)
+{
+ return zbud_alloc(pool, size, handle);
+}
+void zbud_zpool_free(void *pool, unsigned long handle)
+{
+ zbud_free(pool, handle);
+}
+
+int zbud_zpool_shrink(void *pool, size_t size)
+{
+ return zbud_reclaim_page(pool, 8);
+}
+
+void *zbud_zpool_map(void *pool, unsigned long handle,
+ enum zpool_mapmode mm)
+{
+ return zbud_map(pool, handle);
+}
+void zbud_zpool_unmap(void *pool, unsigned long handle)
+{
+ zbud_unmap(pool, handle);
+}
+
+u64 zbud_zpool_total_size(void *pool)
+{
+ return zbud_get_pool_size(pool) * PAGE_SIZE;
+}
+
+static struct zpool_driver zbud_zpool_driver = {
+ .type = "zbud",
+ .create = zbud_zpool_create,
+ .destroy = zbud_zpool_destroy,
+ .malloc = zbud_zpool_malloc,
+ .free = zbud_zpool_free,
+ .shrink = zbud_zpool_shrink,
+ .map = zbud_zpool_map,
+ .unmap =zbud_zpool_unmap,
+ .total_size = zbud_zpool_total_size,
+};
+
+#endif /* CONFIG_ZPOOL */
+
+/*
* Helpers
*/
/* Just to make the code easier to read */
@@ -513,11 +582,20 @@ static int __init init_zbud(void)
/* Make sure the zbud header will fit in one chunk */
BUILD_BUG_ON(sizeof(struct zbud_header) > ZHDR_SIZE_ALIGNED);
pr_info("loaded\n");
+
+#ifdef CONFIG_ZPOOL
+ zpool_register_driver(_zpool_driver);
+#endif
+
return 0;
}
static void __exit exit_zbud(void)
{
+#ifdef CONFIG_ZPOOL
+ zpool_unregister_driver(_zpool_driver);
+#endif
+
pr_info("unloaded\n");
}
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index fe78189..07c3130 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -92,6 +92,7 @@
#include
#include
#include
+#include
/*
* This must be power of 2 and greater than of equal to sizeof(link_free).
@@ -240,6 +241,78 @@ struct mapping_area {
enum zs_mapmode vm_mm; /* mapping mode */
};
+/* zpool driver */
+
+#ifdef CONFIG_ZPOOL
+
+static void *zs_zpool_create(gfp_t gfp, struct zpool_ops *zpool_ops)
+{
+ return zs_create_pool(gfp);
+}
+
+void zs_zpool_destroy(void *pool)
+{
+ zs_destroy_pool(pool);
+}
+
+int zs_zpool_malloc(void *pool, size_t size, unsigned long *handle)
+{
+ *handle = zs_malloc(pool, size);
+ return *handle ? 0 : -1;
+}
+void zs_zpool_free(void *pool, unsigned long handle)
+{
+ zs_free(pool, handle);
+}
+
+int zs_zpool_shrink(void *pool, size_t size)
+{
+ return -EINVAL;
+}
+
+void *zs_zpool_map(void *pool, unsigned long handle,
+ enum zpool_mapmode mm)
+{
+ enum zs_mapmode zs_mm;
+
+ switch (mm) {
+ case ZPOOL_MM_RO:
+ zs_mm = ZS_MM_RO;
+ break;
+ case ZPOOL_MM_WO:
+ zs_mm = ZS_MM_WO;
+ break;
+ case ZPOOL_MM_RW: /* fallthru */
+ default:
+ zs_mm = ZS_MM_RW;
+ break;
+ }
+
+ return zs_map_object(pool, handle, zs_mm);
+}
+void zs_zpool_unmap(void *pool, unsigned long handle)
+{
+ zs_unmap_object(pool, handle);
+}
+
+u64 zs_zpool_total_size(void *pool)
+{
+ return zs_get_total_size_bytes(pool);
+}
+
+static struct zpool_driver zs_zpool_driver = {
+ .type = "zsmalloc",
+ .create = zs_zpool_create,
+ .destroy = zs_zpool_destroy,
+ .malloc = zs_zpool_malloc,
+ .free = zs_zpool_free,
+ .shrink = zs_zpool_shrink,
+ .map = zs_zpool_map,
+ .unmap =zs_zpool_unmap,
+ .total_size = zs_zpool_total_size,
+};
+
+#endif /* CONFIG_ZPOOL */
/* per-cpu VM mapping areas for zspage accesses that cross page boundaries */
static DEFINE_PER_CPU(struct mapping_area,
[PATCHv2 1/6] mm/zbud: zbud_alloc() minor param change
Change zbud to store gfp_t flags passed at pool creation to use for
each alloc; this allows the api to be closer to the existing zsmalloc
interface, and the only current zbud user (zswap) uses the same gfp
flags for all allocs. Update zswap to use changed interface.
Signed-off-by: Dan Streetman
Acked-by: Seth Jennings
Cc: Weijie Yang
---
No change since v2 : https://lkml.org/lkml/2014/5/7/727
Changes since v1 https://lkml.org/lkml/2014/4/19/98
-context changes only; zbud_alloc parameter type changed since
last patch
include/linux/zbud.h | 2 +-
mm/zbud.c| 27 +++
mm/zswap.c | 6 +++---
3 files changed, 19 insertions(+), 16 deletions(-)
diff --git a/include/linux/zbud.h b/include/linux/zbud.h
index 13af0d4..0b2534e 100644
--- a/include/linux/zbud.h
+++ b/include/linux/zbud.h
@@ -11,7 +11,7 @@ struct zbud_ops {
struct zbud_pool *zbud_create_pool(gfp_t gfp, struct zbud_ops *ops);
void zbud_destroy_pool(struct zbud_pool *pool);
-int zbud_alloc(struct zbud_pool *pool, unsigned int size, gfp_t gfp,
+int zbud_alloc(struct zbud_pool *pool, unsigned int size,
unsigned long *handle);
void zbud_free(struct zbud_pool *pool, unsigned long handle);
int zbud_reclaim_page(struct zbud_pool *pool, unsigned int retries);
diff --git a/mm/zbud.c b/mm/zbud.c
index 01df13a..847c01c 100644
--- a/mm/zbud.c
+++ b/mm/zbud.c
@@ -94,6 +94,7 @@ struct zbud_pool {
struct list_head lru;
u64 pages_nr;
struct zbud_ops *ops;
+ gfp_t gfp;
};
/*
@@ -193,9 +194,12 @@ static int num_free_chunks(struct zbud_header *zhdr)
*/
/**
* zbud_create_pool() - create a new zbud pool
- * @gfp: gfp flags when allocating the zbud pool structure
+ * @gfp: gfp flags when growing the pool
* @ops: user-defined operations for the zbud pool
*
+ * gfp should not set __GFP_HIGHMEM as highmem pages cannot be used
+ * as zbud pool pages.
+ *
* Return: pointer to the new zbud pool or NULL if the metadata allocation
* failed.
*/
@@ -204,7 +208,9 @@ struct zbud_pool *zbud_create_pool(gfp_t gfp, struct
zbud_ops *ops)
struct zbud_pool *pool;
int i;
- pool = kmalloc(sizeof(struct zbud_pool), gfp);
+ if (gfp & __GFP_HIGHMEM)
+ return NULL;
+ pool = kmalloc(sizeof(struct zbud_pool), GFP_KERNEL);
if (!pool)
return NULL;
spin_lock_init(>lock);
@@ -214,6 +220,7 @@ struct zbud_pool *zbud_create_pool(gfp_t gfp, struct
zbud_ops *ops)
INIT_LIST_HEAD(>lru);
pool->pages_nr = 0;
pool->ops = ops;
+ pool->gfp = gfp;
return pool;
}
@@ -232,7 +239,6 @@ void zbud_destroy_pool(struct zbud_pool *pool)
* zbud_alloc() - allocates a region of a given size
* @pool: zbud pool from which to allocate
* @size: size in bytes of the desired allocation
- * @gfp: gfp flags used if the pool needs to grow
* @handle:handle of the new allocation
*
* This function will attempt to find a free region in the pool large enough to
@@ -240,14 +246,11 @@ void zbud_destroy_pool(struct zbud_pool *pool)
* performed first. If no suitable free region is found, then a new page is
* allocated and added to the pool to satisfy the request.
*
- * gfp should not set __GFP_HIGHMEM as highmem pages cannot be used
- * as zbud pool pages.
- *
- * Return: 0 if success and handle is set, otherwise -EINVAL if the size or
- * gfp arguments are invalid or -ENOMEM if the pool was unable to allocate
- * a new page.
+ * Return: 0 if success and @handle is set, -ENOSPC if the @size is too large,
+ * -EINVAL if the @size is 0, or -ENOMEM if the pool was unable to
+ * allocate a new page.
*/
-int zbud_alloc(struct zbud_pool *pool, unsigned int size, gfp_t gfp,
+int zbud_alloc(struct zbud_pool *pool, unsigned int size,
unsigned long *handle)
{
int chunks, i, freechunks;
@@ -255,7 +258,7 @@ int zbud_alloc(struct zbud_pool *pool, unsigned int size,
gfp_t gfp,
enum buddy bud;
struct page *page;
- if (!size || (gfp & __GFP_HIGHMEM))
+ if (!size)
return -EINVAL;
if (size > PAGE_SIZE - ZHDR_SIZE_ALIGNED - CHUNK_SIZE)
return -ENOSPC;
@@ -279,7 +282,7 @@ int zbud_alloc(struct zbud_pool *pool, unsigned int size,
gfp_t gfp,
/* Couldn't find unbuddied zbud page, create new one */
spin_unlock(>lock);
- page = alloc_page(gfp);
+ page = alloc_page(pool->gfp);
if (!page)
return -ENOMEM;
spin_lock(>lock);
diff --git a/mm/zswap.c b/mm/zswap.c
index aeaef0f..1cc6770 100644
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -679,8 +679,7 @@ static int zswap_frontswap_store(unsigned type, pgoff_t
offset,
/* store */
len = dlen + sizeof(struct zswap_header);
- ret = zbud_alloc(zswap_pool, len, __GFP_NORETRY | __GFP_NOWARN,
- );
+ ret =
[PATCHv3 5/6] mm/zpool: update zswap to use zpool
Change zswap to use the zpool api instead of directly using zbud.
Add a boot-time param to allow selecting which zpool implementation
to use, with zbud as the default.
Signed-off-by: Dan Streetman
Cc: Seth Jennings
Cc: Weijie Yang
---
Changes since v2 : https://lkml.org/lkml/2014/5/7/894
-change zswap to select ZPOOL instead of ZBUD
-only try zbud default if not already tried
Changes since v1 https://lkml.org/lkml/2014/4/19/102
-since zpool fallback is removed, manually fall back to zbud if
specified type fails
mm/Kconfig | 2 +-
mm/zswap.c | 76 +-
2 files changed, 46 insertions(+), 32 deletions(-)
diff --git a/mm/Kconfig b/mm/Kconfig
index 00f7720..5ae0016 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -531,7 +531,7 @@ config ZSWAP
bool "Compressed cache for swap pages (EXPERIMENTAL)"
depends on FRONTSWAP && CRYPTO=y
select CRYPTO_LZO
- select ZBUD
+ select ZPOOL
default n
help
A lightweight compressed cache for swap pages. It takes
diff --git a/mm/zswap.c b/mm/zswap.c
index 1cc6770..3b54715 100644
--- a/mm/zswap.c
+++ b/mm/zswap.c
@@ -34,7 +34,7 @@
#include
#include
#include
-#include
+#include
#include
#include
@@ -45,8 +45,8 @@
/*
* statistics
**/
-/* Number of memory pages used by the compressed pool */
-static u64 zswap_pool_pages;
+/* Total bytes used by the compressed storage */
+static u64 zswap_pool_total_size;
/* The number of compressed pages currently stored in zswap */
static atomic_t zswap_stored_pages = ATOMIC_INIT(0);
@@ -89,8 +89,13 @@ static unsigned int zswap_max_pool_percent = 20;
module_param_named(max_pool_percent,
zswap_max_pool_percent, uint, 0644);
-/* zbud_pool is shared by all of zswap backend */
-static struct zbud_pool *zswap_pool;
+/* Compressed storage to use */
+#define ZSWAP_ZPOOL_DEFAULT "zbud"
+static char *zswap_zpool_type = ZSWAP_ZPOOL_DEFAULT;
+module_param_named(zpool, zswap_zpool_type, charp, 0444);
+
+/* zpool is shared by all of zswap backend */
+static struct zpool *zswap_pool;
/*
* compression functions
@@ -168,7 +173,7 @@ static void zswap_comp_exit(void)
*be held while changing the refcount. Since the lock must
*be held, there is no reason to also make refcount atomic.
* offset - the swap offset for the entry. Index into the red-black tree.
- * handle - zbud allocation handle that stores the compressed page data
+ * handle - zpool allocation handle that stores the compressed page data
* length - the length in bytes of the compressed page data. Needed during
* decompression
*/
@@ -284,15 +289,15 @@ static void zswap_rb_erase(struct rb_root *root, struct
zswap_entry *entry)
}
/*
- * Carries out the common pattern of freeing and entry's zbud allocation,
+ * Carries out the common pattern of freeing and entry's zpool allocation,
* freeing the entry itself, and decrementing the number of stored pages.
*/
static void zswap_free_entry(struct zswap_entry *entry)
{
- zbud_free(zswap_pool, entry->handle);
+ zpool_free(zswap_pool, entry->handle);
zswap_entry_cache_free(entry);
atomic_dec(_stored_pages);
- zswap_pool_pages = zbud_get_pool_size(zswap_pool);
+ zswap_pool_total_size = zpool_get_total_size(zswap_pool);
}
/* caller must hold the tree lock */
@@ -409,7 +414,7 @@ cleanup:
static bool zswap_is_full(void)
{
return totalram_pages * zswap_max_pool_percent / 100 <
- zswap_pool_pages;
+ DIV_ROUND_UP(zswap_pool_total_size, PAGE_SIZE);
}
/*
@@ -525,7 +530,7 @@ static int zswap_get_swap_cache_page(swp_entry_t entry,
* the swap cache, the compressed version stored by zswap can be
* freed.
*/
-static int zswap_writeback_entry(struct zbud_pool *pool, unsigned long handle)
+static int zswap_writeback_entry(struct zpool *pool, unsigned long handle)
{
struct zswap_header *zhdr;
swp_entry_t swpentry;
@@ -541,9 +546,9 @@ static int zswap_writeback_entry(struct zbud_pool *pool,
unsigned long handle)
};
/* extract swpentry from data */
- zhdr = zbud_map(pool, handle);
+ zhdr = zpool_map_handle(pool, handle, ZPOOL_MM_RO);
swpentry = zhdr->swpentry; /* here */
- zbud_unmap(pool, handle);
+ zpool_unmap_handle(pool, handle);
tree = zswap_trees[swp_type(swpentry)];
offset = swp_offset(swpentry);
@@ -573,13 +578,13 @@ static int zswap_writeback_entry(struct zbud_pool *pool,
unsigned long handle)
case ZSWAP_SWAPCACHE_NEW: /* page is locked */
/* decompress */
dlen = PAGE_SIZE;
- src = (u8 *)zbud_map(zswap_pool, entry->handle) +
- sizeof(struct zswap_header);
+
[PATCHv3 3/6] mm/zpool: implement common zpool api to zbud/zsmalloc
Add zpool api.
zpool provides an interface for memory storage, typically of compressed
memory. Users can select what backend to use; currently the only
implementations are zbud, a low density implementation with up to
two compressed pages per storage page, and zsmalloc, a higher density
implementation with multiple compressed pages per storage page.
Signed-off-by: Dan Streetman
Cc: Seth Jennings
Cc: Minchan Kim
Cc: Nitin Gupta
Cc: Weijie Yang
---
Note this patch set is against the mmotm tree at
git://git.cmpxchg.org/linux-mmotm.git
This patch may need context changes to the -next or other trees.
Changes since v2 : https://lkml.org/lkml/2014/5/7/733
-Remove hardcoded zbud/zsmalloc implementations
-Add driver (un)register functions
Changes since v1 https://lkml.org/lkml/2014/4/19/101
-add some pr_info() during creation and pr_err() on errors
-remove zpool code to call zs_shrink(), since zsmalloc shrinking
was removed from this patchset
-remove fallback; only specified pool type will be tried
-pr_fmt() is defined in zpool to prefix zpool: in any pr_XXX() calls
include/linux/zpool.h | 214 ++
mm/Kconfig| 41 ++
mm/Makefile | 1 +
mm/zpool.c| 197 ++
4 files changed, 436 insertions(+), 17 deletions(-)
create mode 100644 include/linux/zpool.h
create mode 100644 mm/zpool.c
diff --git a/include/linux/zpool.h b/include/linux/zpool.h
new file mode 100644
index 000..699ac9b
--- /dev/null
+++ b/include/linux/zpool.h
@@ -0,0 +1,214 @@
+/*
+ * zpool memory storage api
+ *
+ * Copyright (C) 2014 Dan Streetman
+ *
+ * This is a common frontend for the zbud and zsmalloc memory
+ * storage pool implementations. Typically, this is used to
+ * store compressed memory.
+ */
+
+#ifndef _ZPOOL_H_
+#define _ZPOOL_H_
+
+struct zpool;
+
+struct zpool_ops {
+ int (*evict)(struct zpool *pool, unsigned long handle);
+};
+
+/*
+ * Control how a handle is mapped. It will be ignored if the
+ * implementation does not support it. Its use is optional.
+ * Note that this does not refer to memory protection, it
+ * refers to how the memory will be copied in/out if copying
+ * is necessary during mapping; read-write is the safest as
+ * it copies the existing memory in on map, and copies the
+ * changed memory back out on unmap. Write-only does not copy
+ * in the memory and should only be used for initialization.
+ * If in doubt, use ZPOOL_MM_DEFAULT which is read-write.
+ */
+enum zpool_mapmode {
+ ZPOOL_MM_RW, /* normal read-write mapping */
+ ZPOOL_MM_RO, /* read-only (no copy-out at unmap time) */
+ ZPOOL_MM_WO, /* write-only (no copy-in at map time) */
+
+ ZPOOL_MM_DEFAULT = ZPOOL_MM_RW
+};
+
+/**
+ * zpool_create_pool() - Create a new zpool
+ * @type The type of the zpool to create (e.g. zbud, zsmalloc)
+ * @flags What GFP flags should be used when the zpool allocates memory.
+ * @opsThe optional ops callback.
+ *
+ * This creates a new zpool of the specified type. The zpool will use the
+ * given flags when allocating any memory. If the ops param is NULL, then
+ * the created zpool will not be shrinkable.
+ *
+ * Returns: New zpool on success, NULL on failure.
+ */
+struct zpool *zpool_create_pool(char *type, gfp_t flags,
+ struct zpool_ops *ops);
+
+/**
+ * zpool_get_type() - Get the type of the zpool
+ * @pool The zpool to check
+ *
+ * This returns the type of the pool.
+ *
+ * Returns: The type of zpool.
+ */
+char *zpool_get_type(struct zpool *pool);
+
+/**
+ * zpool_destroy_pool() - Destroy a zpool
+ * @pool The zpool to destroy.
+ *
+ * This destroys an existing zpool. The zpool should not be in use.
+ */
+void zpool_destroy_pool(struct zpool *pool);
+
+/**
+ * zpool_malloc() - Allocate memory
+ * @pool The zpool to allocate from.
+ * @size The amount of memory to allocate.
+ * @handle Pointer to the handle to set
+ *
+ * This allocates the requested amount of memory from the pool.
+ * The provided @handle will be set to the allocated object handle.
+ *
+ * Returns: 0 on success, negative value on error.
+ */
+int zpool_malloc(struct zpool *pool, size_t size, unsigned long *handle);
+
+/**
+ * zpool_free() - Free previously allocated memory
+ * @pool The zpool that allocated the memory.
+ * @handle The handle to the memory to free.
+ *
+ * This frees previously allocated memory. This does not guarantee
+ * that the pool will actually free memory, only that the memory
+ * in the pool will become available for use by the pool.
+ */
+void zpool_free(struct zpool *pool, unsigned long handle);
+
+/**
+ * zpool_shrink() - Shrink the pool size
+ * @pool The zpool to shrink.
+ * @size The minimum amount to shrink the pool.
+ *
+ * This attempts to shrink the actual memory size of the pool
+ * by evicting currently used handle(s). If
[PATCH 6/6] mm/zpool: prevent zbud/zsmalloc from unloading when used
Add try_module_get() to pool creation functions for zbud and zsmalloc,
and module_put() to pool destruction functions, since they now can be
modules used via zpool. Without usage counting, they could be unloaded
while pool(s) were active, resulting in an oops.
Signed-off-by: Dan Streetman
Cc: Seth Jennings
Cc: Minchan Kim
Cc: Nitin Gupta
Cc: Weijie Yang
---
New for this patch set.
mm/zbud.c | 5 +
mm/zsmalloc.c | 5 +
2 files changed, 10 insertions(+)
diff --git a/mm/zbud.c b/mm/zbud.c
index 8a72cb1..2b3689c 100644
--- a/mm/zbud.c
+++ b/mm/zbud.c
@@ -282,6 +282,10 @@ struct zbud_pool *zbud_create_pool(gfp_t gfp, struct
zbud_ops *ops)
pool = kmalloc(sizeof(struct zbud_pool), GFP_KERNEL);
if (!pool)
return NULL;
+ if (!try_module_get(THIS_MODULE)) {
+ kfree(pool);
+ return NULL;
+ }
spin_lock_init(>lock);
for_each_unbuddied_list(i, 0)
INIT_LIST_HEAD(>unbuddied[i]);
@@ -302,6 +306,7 @@ struct zbud_pool *zbud_create_pool(gfp_t gfp, struct
zbud_ops *ops)
void zbud_destroy_pool(struct zbud_pool *pool)
{
kfree(pool);
+ module_put(THIS_MODULE);
}
/**
diff --git a/mm/zsmalloc.c b/mm/zsmalloc.c
index 07c3130..2cc2647 100644
--- a/mm/zsmalloc.c
+++ b/mm/zsmalloc.c
@@ -946,6 +946,10 @@ struct zs_pool *zs_create_pool(gfp_t flags)
pool = kzalloc(ovhd_size, GFP_KERNEL);
if (!pool)
return NULL;
+ if (!try_module_get(THIS_MODULE)) {
+ kfree(pool);
+ return NULL;
+ }
for (i = 0; i < ZS_SIZE_CLASSES; i++) {
int size;
@@ -985,6 +989,7 @@ void zs_destroy_pool(struct zs_pool *pool)
}
}
kfree(pool);
+ module_put(THIS_MODULE);
}
EXPORT_SYMBOL_GPL(zs_destroy_pool);
--
1.8.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv3 0/6] mm/zpool: add common api for zswap to use zbud/zsmalloc
In order to allow zswap users to choose between zbud and zsmalloc for the compressed storage pool, this patch set adds a new api "zpool" that provides an interface to both zbud and zsmalloc. Only minor changes to zbud's interface were needed. This does not include implementing shrinking in zsmalloc, which will be sent separately. I believe Seth originally was using zsmalloc for swap, but there were concerns about how significant the impact of shrinking zsmalloc would be when zswap had to start reclaiming pages. That still may be an issue, but this at least allows users to choose themselves whether they want a lower-density or higher-density compressed storage medium. At least for situations where zswap reclaim is never or rarely reached, it probably makes sense to use the higher density of zsmalloc. Note this patch set does not change zram to use zpool, although that change should be possible as well. --- Changes since v2 : https://lkml.org/lkml/2014/5/7/927 -Change zpool to use driver registration instead of hardcoding implementations -Add module use counting in zbud/zsmalloc Changes since v1 https://lkml.org/lkml/2014/4/19/97 -remove zsmalloc shrinking -change zbud size param type from unsigned int to size_t -remove zpool fallback creation -zswap manually falls back to zbud if specified type fails Dan Streetman (6): mm/zbud: zbud_alloc() minor param change mm/zbud: change zbud_alloc size type to size_t mm/zpool: implement common zpool api to zbud/zsmalloc mm/zpool: zbud/zsmalloc implement zpool mm/zpool: update zswap to use zpool mm/zpool: prevent zbud/zsmalloc from unloading when used include/linux/zbud.h | 2 +- include/linux/zpool.h | 214 ++ mm/Kconfig| 43 +- mm/Makefile | 1 + mm/zbud.c | 113 ++ mm/zpool.c| 197 ++ mm/zsmalloc.c | 86 mm/zswap.c| 76 ++ 8 files changed, 668 insertions(+), 64 deletions(-) create mode 100644 include/linux/zpool.h create mode 100644 mm/zpool.c -- 1.8.3.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 21/24] ARM64:ILP32: The native siginfo is used instead of the compat siginfo.
On 05/24/2014 12:02 AM, Andrew Pinski wrote: > > +/* ILP32 uses the native siginfo and not the compat struct */ > +#define COMPAT_USE_NATIVE_SIGINFO!is_a32_compat_task() > + Probably want parens around that expression? -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] msi3103: Use time_before_eq()
To be future-proof and for better readability the time comparisons are
modified to use time_before_eq() instead of plain, error-prone math.
Signed-off-by: Manuel Schölling
---
drivers/staging/media/msi3101/sdr-msi3101.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/media/msi3101/sdr-msi3101.c
b/drivers/staging/media/msi3101/sdr-msi3101.c
index 65d351f..b52726b 100644
--- a/drivers/staging/media/msi3101/sdr-msi3101.c
+++ b/drivers/staging/media/msi3101/sdr-msi3101.c
@@ -208,7 +208,7 @@ static int msi3101_convert_stream_504(struct msi3101_state
*s, u8 *dst,
}
/* calculate samping rate and output it in 10 seconds intervals */
- if ((s->jiffies_next + msecs_to_jiffies(1)) <= jiffies) {
+ if (time_before_eq(s->jiffies_next + 10 * HZ, jiffies)) {
unsigned long jiffies_now = jiffies;
unsigned long msecs = jiffies_to_msecs(jiffies_now) -
jiffies_to_msecs(s->jiffies_next);
unsigned int samples = sample_num[i_max - 1] - s->sample;
@@ -360,7 +360,7 @@ static int msi3101_convert_stream_384(struct msi3101_state
*s, u8 *dst,
}
/* calculate samping rate and output it in 10 seconds intervals */
- if ((s->jiffies_next + msecs_to_jiffies(1)) <= jiffies) {
+ if (time_before_eq(s->jiffies_next + 10 * HZ, jiffies)) {
unsigned long jiffies_now = jiffies;
unsigned long msecs = jiffies_to_msecs(jiffies_now) -
jiffies_to_msecs(s->jiffies_next);
unsigned int samples = sample_num[i_max - 1] - s->sample;
@@ -425,7 +425,7 @@ static int msi3101_convert_stream_336(struct msi3101_state
*s, u8 *dst,
}
/* calculate samping rate and output it in 10 seconds intervals */
- if ((s->jiffies_next + msecs_to_jiffies(1)) <= jiffies) {
+ if (time_before_eq(s->jiffies_next + 10 * HZ, jiffies)) {
unsigned long jiffies_now = jiffies;
unsigned long msecs = jiffies_to_msecs(jiffies_now) -
jiffies_to_msecs(s->jiffies_next);
unsigned int samples = sample_num[i_max - 1] - s->sample;
@@ -488,7 +488,7 @@ static int msi3101_convert_stream_252(struct msi3101_state
*s, u8 *dst,
}
/* calculate samping rate and output it in 10 seconds intervals */
- if ((s->jiffies_next + msecs_to_jiffies(1)) <= jiffies) {
+ if (time_before_eq(s->jiffies_next + 10 * HZ, jiffies)) {
unsigned long jiffies_now = jiffies;
unsigned long msecs = jiffies_to_msecs(jiffies_now) -
jiffies_to_msecs(s->jiffies_next);
unsigned int samples = sample_num[i_max - 1] - s->sample;
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] parport: Add support for the WCH353 1S/1P multi-IO card
(Ccing linux-serial)
On 24 May 03:24 PM, Ezequiel Garcia wrote:
> This Multi-IO card has one serial 16550-like and one parallel port connector.
> Here's the lspci output, after this commit is applied:
>
> 03:07.0 Serial controller: Device 4348:5053 (rev 10) (prog-if 02 [16550])
> Subsystem: Device 4348:5053
> Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
> Stepping- SERR- FastB2B- DisINTx-
> Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
> SERR-Interrupt: pin A routed to IRQ 21
> Region 0: I/O ports at cf00 [size=8]
> Region 1: I/O ports at ce00 [size=8]
> Kernel driver in use: parport_serial
> Kernel modules: 8250_pci, parport_serial
>
> This commit adds an entry with the device ID to the blacklist declared in
> 8250_pci to prevent the driver from taking ownership. Also, and as was done
> for the 2S/1P variant, add a quirk to skip autodetection and set the correct
> type to 16550A clone.
>
> Proper entries are added to parport_serial, to support the device parallel
> and serial ports.
>
> Cc: Gianluca Anzolin
> Cc: Alan Cox
> Cc: Greg Kroah-Hartman
> Signed-off-by: Ezequiel Garcia
> ---
> drivers/parport/parport_serial.c | 9 +
> drivers/tty/serial/8250/8250_pci.c | 10 ++
> 2 files changed, 19 insertions(+)
>
> diff --git a/drivers/parport/parport_serial.c
> b/drivers/parport/parport_serial.c
> index ff53314..ee93200 100644
> --- a/drivers/parport/parport_serial.c
> +++ b/drivers/parport/parport_serial.c
> @@ -62,6 +62,7 @@ enum parport_pc_pci_cards {
> timedia_9079a,
> timedia_9079b,
> timedia_9079c,
> + wch_ch353_1s1p,
> wch_ch353_2s1p,
> sunix_2s1p,
> };
> @@ -148,6 +149,7 @@ static struct parport_pc_pci cards[] = {
> /* timedia_9079a */ { 1, { { 2, 3 }, } },
> /* timedia_9079b */ { 1, { { 2, 3 }, } },
> /* timedia_9079c */ { 1, { { 2, 3 }, } },
> + /* wch_ch353_1s1p*/ { 1, { { 1, -1}, } },
> /* wch_ch353_2s1p*/ { 1, { { 2, -1}, } },
> /* sunix_2s1p */{ 1, { { 3, -1 }, } },
> };
> @@ -253,6 +255,7 @@ static struct pci_device_id parport_serial_pci_tbl[] = {
> { 0x1409, 0x7168, 0x1409, 0xd079, 0, 0, timedia_9079c },
>
> /* WCH CARDS */
> + { 0x4348, 0x5053, PCI_ANY_ID, PCI_ANY_ID, 0, 0, wch_ch353_1s1p},
> { 0x4348, 0x7053, 0x4348, 0x3253, 0, 0, wch_ch353_2s1p},
>
> /*
> @@ -479,6 +482,12 @@ static struct pciserial_board
> pci_parport_serial_boards[] = {
> .base_baud = 921600,
> .uart_offset= 8,
> },
> + [wch_ch353_1s1p] = {
> + .flags = FL_BASE0|FL_BASE_BARS,
> + .num_ports = 1,
> + .base_baud = 115200,
> + .uart_offset= 8,
> + },
> [wch_ch353_2s1p] = {
> .flags = FL_BASE0|FL_BASE_BARS,
> .num_ports = 2,
> diff --git a/drivers/tty/serial/8250/8250_pci.c
> b/drivers/tty/serial/8250/8250_pci.c
> index b14bcba..f35a85f 100644
> --- a/drivers/tty/serial/8250/8250_pci.c
> +++ b/drivers/tty/serial/8250/8250_pci.c
> @@ -1778,6 +1778,7 @@ pci_wch_ch353_setup(struct serial_private *priv,
> #define PCI_DEVICE_ID_WCH_CH352_2S 0x3253
> #define PCI_DEVICE_ID_WCH_CH353_4S 0x3453
> #define PCI_DEVICE_ID_WCH_CH353_2S1PF0x5046
> +#define PCI_DEVICE_ID_WCH_CH353_1S1P 0x5053
> #define PCI_DEVICE_ID_WCH_CH353_2S1P 0x7053
> #define PCI_VENDOR_ID_AGESTAR0x5372
> #define PCI_DEVICE_ID_AGESTAR_9375 0x6872
> @@ -2410,6 +2411,14 @@ static struct pci_serial_quirk pci_serial_quirks[]
> __refdata = {
> .subdevice = PCI_ANY_ID,
> .setup = pci_omegapci_setup,
> },
> + /* WCH CH353 1S1P card (16550 clone) */
> + {
> + .vendor = PCI_VENDOR_ID_WCH,
> + .device = PCI_DEVICE_ID_WCH_CH353_1S1P,
> + .subvendor = PCI_ANY_ID,
> + .subdevice = PCI_ANY_ID,
> + .setup = pci_wch_ch353_setup,
> + },
> /* WCH CH353 2S1P card (16550 clone) */
> {
> .vendor = PCI_VENDOR_ID_WCH,
> @@ -3526,6 +3535,7 @@ static const struct pci_device_id blacklist[] = {
>
> /* multi-io cards handled by parport_serial */
> { PCI_DEVICE(0x4348, 0x7053), }, /* WCH CH353 2S1P */
> + { PCI_DEVICE(0x4348, 0x5053), }, /* WCH CH353 1S1P */
> };
>
> /*
> --
> 1.9.1
>
--
Ezequiel García, Free Electrons
Embedded Linux, Kernel and Android Engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] parport: Add support for the WCH353 1S/1P multi-IO card
This Multi-IO card has one serial 16550-like and one parallel port connector.
Here's the lspci output, after this commit is applied:
03:07.0 Serial controller: Device 4348:5053 (rev 10) (prog-if 02 [16550])
Subsystem: Device 4348:5053
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR-
Cc: Alan Cox
Cc: Greg Kroah-Hartman
Signed-off-by: Ezequiel Garcia
---
drivers/parport/parport_serial.c | 9 +
drivers/tty/serial/8250/8250_pci.c | 10 ++
2 files changed, 19 insertions(+)
diff --git a/drivers/parport/parport_serial.c b/drivers/parport/parport_serial.c
index ff53314..ee93200 100644
--- a/drivers/parport/parport_serial.c
+++ b/drivers/parport/parport_serial.c
@@ -62,6 +62,7 @@ enum parport_pc_pci_cards {
timedia_9079a,
timedia_9079b,
timedia_9079c,
+ wch_ch353_1s1p,
wch_ch353_2s1p,
sunix_2s1p,
};
@@ -148,6 +149,7 @@ static struct parport_pc_pci cards[] = {
/* timedia_9079a */ { 1, { { 2, 3 }, } },
/* timedia_9079b */ { 1, { { 2, 3 }, } },
/* timedia_9079c */ { 1, { { 2, 3 }, } },
+ /* wch_ch353_1s1p*/ { 1, { { 1, -1}, } },
/* wch_ch353_2s1p*/ { 1, { { 2, -1}, } },
/* sunix_2s1p */{ 1, { { 3, -1 }, } },
};
@@ -253,6 +255,7 @@ static struct pci_device_id parport_serial_pci_tbl[] = {
{ 0x1409, 0x7168, 0x1409, 0xd079, 0, 0, timedia_9079c },
/* WCH CARDS */
+ { 0x4348, 0x5053, PCI_ANY_ID, PCI_ANY_ID, 0, 0, wch_ch353_1s1p},
{ 0x4348, 0x7053, 0x4348, 0x3253, 0, 0, wch_ch353_2s1p},
/*
@@ -479,6 +482,12 @@ static struct pciserial_board pci_parport_serial_boards[]
= {
.base_baud = 921600,
.uart_offset= 8,
},
+ [wch_ch353_1s1p] = {
+ .flags = FL_BASE0|FL_BASE_BARS,
+ .num_ports = 1,
+ .base_baud = 115200,
+ .uart_offset= 8,
+ },
[wch_ch353_2s1p] = {
.flags = FL_BASE0|FL_BASE_BARS,
.num_ports = 2,
diff --git a/drivers/tty/serial/8250/8250_pci.c
b/drivers/tty/serial/8250/8250_pci.c
index b14bcba..f35a85f 100644
--- a/drivers/tty/serial/8250/8250_pci.c
+++ b/drivers/tty/serial/8250/8250_pci.c
@@ -1778,6 +1778,7 @@ pci_wch_ch353_setup(struct serial_private *priv,
#define PCI_DEVICE_ID_WCH_CH352_2S 0x3253
#define PCI_DEVICE_ID_WCH_CH353_4S 0x3453
#define PCI_DEVICE_ID_WCH_CH353_2S1PF 0x5046
+#define PCI_DEVICE_ID_WCH_CH353_1S1P 0x5053
#define PCI_DEVICE_ID_WCH_CH353_2S1P 0x7053
#define PCI_VENDOR_ID_AGESTAR 0x5372
#define PCI_DEVICE_ID_AGESTAR_9375 0x6872
@@ -2410,6 +2411,14 @@ static struct pci_serial_quirk pci_serial_quirks[]
__refdata = {
.subdevice = PCI_ANY_ID,
.setup = pci_omegapci_setup,
},
+ /* WCH CH353 1S1P card (16550 clone) */
+ {
+ .vendor = PCI_VENDOR_ID_WCH,
+ .device = PCI_DEVICE_ID_WCH_CH353_1S1P,
+ .subvendor = PCI_ANY_ID,
+ .subdevice = PCI_ANY_ID,
+ .setup = pci_wch_ch353_setup,
+ },
/* WCH CH353 2S1P card (16550 clone) */
{
.vendor = PCI_VENDOR_ID_WCH,
@@ -3526,6 +3535,7 @@ static const struct pci_device_id blacklist[] = {
/* multi-io cards handled by parport_serial */
{ PCI_DEVICE(0x4348, 0x7053), }, /* WCH CH353 2S1P */
+ { PCI_DEVICE(0x4348, 0x5053), }, /* WCH CH353 1S1P */
};
/*
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: randconfig build error with next-20140523, in net/bridge/br_netfilter.c
From: Jim Davis Date: Fri, 23 May 2014 13:06:48 -0700 > Building with the attached random configuration file, > > warning: (BRIDGE_NF_EBTABLES) selects NETFILTER_XTABLES which has > unmet direct dependencies (NET && INET && NETFILTER) > warning: (NF_TABLES_BRIDGE && BRIDGE_NF_EBTABLES) selects > BRIDGE_NETFILTER which has unmet direct dependencies (NET && BRIDGE && > NETFILTER && INET && NETFILTER_ADVANCED) > > net/built-in.o: In function `br_parse_ip_options': > br_netfilter.c:(.text+0x4a5ba): undefined reference to `ip_options_compile' > br_netfilter.c:(.text+0x4a5ed): undefined reference to `ip_options_rcv_srr' > net/built-in.o: In function `br_nf_pre_routing_finish': > br_netfilter.c:(.text+0x4a8a4): undefined reference to `ip_route_input_noref' > br_netfilter.c:(.text+0x4a987): undefined reference to `ip_route_output_flow' > make: *** [vmlinux] Error 1 This problem was introduced by: commit f5efc696cc711021cc73e7543cc3038e58459707 Author: Tomasz Bursztyka Date: Mon Apr 14 15:41:28 2014 +0300 netfilter: nf_tables: Add meta expression key for bridge interface name You can't use "select BRIDGE_NETFILTER" for NF_TABLES_BRIDGE, because it is BRIDGE_NETFILTER which provides the proper dependencies, and in particular the crucial "INET" dependency. When you use a hammer like "select" it bypasses the dependencies which are usually enforced by BRIDGE_NETFILTER and causes the problems we are seeing here. Pablo please fix this, thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] of: Ensure unique names without sacrificing determinism
On 23 May 08:36 AM, Grant Likely wrote: > The way the driver core is implemented, every device using the same bus > type is required to have a unique name because a symlink to each device > is created in the appropriate /sys/bus/*/devices directory, and two > identical names causes a collision. > > The current code handles the requirement by using an globally > incremented counter that is appended to the device name. It works, but > it means any change to device registration will change the assigned > numbers. Instead, if we build up the name by using information from the > parent nodes, then it can be guaranteed to be unique without adding a > random number to the end of it. > > Signed-off-by: Grant Likely Tested-by: Ezequiel Garcia -- Ezequiel Garcia, VanguardiaSur www.vanguardiasur.com.ar -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: pull request: wireless 2014-05-23
From: "John W. Linville" Date: Fri, 23 May 2014 11:07:34 -0400 > I have two more fixes intended for the 3.15 stream... > > For the iwlwifi one, Emmanuel says: > > "A race has been discovered in the beacon filtering code. Since the > fix is too big for 3.15, I disable here the feature." > > For the bluetooth one, Gustavo says: > > "This pull request contains a very important fix for 3.15. Here we fix the > permissions of a debugfs file that would otherwise allow unauthorized users > to write content to it." > > Please let me know if there are problems! Pulled, thanks a lot John. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/4] ks8851 DT/regulator/gpio updates
From: Stephen Boyd Date: Fri, 23 May 2014 12:57:16 -0700 > This set of patches properly documents the micrel ks8851 spi ethernet > controller, converts to devm_regulator_get_optional() to make error > paths slightly simpler, and finally adds supports for another > optional regulator and a reset gpio. This allows me to use the ks8851 > on my MSM8960 CDP board. > > Changes since v1: > * Dropped vendor prefix patch as that should go through DT tree Series applied, thanks Stephen! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
CMWQ workqueue questions
Hi, I was trying to understand the workqueues in more details: e.g. it is given kworker/u4:0 kworker/0:0 What does u4:0 represents and similarily 0:0 represents. I was glancing into the code when pool->cpu>0, there is u appended. Can you please explain u4:0 and 0:0 (what does it represent) in workqueue kworker? Regards, D. Raj-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] crypto: Add Allwinner Security System crypto accelerator
On Friday, May 23, 2014 at 12:46:10 PM, Arnd Bergmann wrote: > On Thursday 22 May 2014, Corentin LABBE wrote: > > Le 22/05/2014 17:28, Arnd Bergmann a écrit : > > > On Thursday 22 May 2014 17:09:56 LABBE Corentin wrote: > > >> Signed-off-by: LABBE Corentin > > > > > > My feeling is that this should either be one driver that provides > > > all five algorithms unconditionally, or five drivers that are each > > > separate loadable modules and based on top of a common module > > > that only exports functions but has no active logic itself > > > > I agree for the split. > > It was my first intention but I feared to add too many files. > > So I propose to split in 6, sunxi-ss-hash.c, sunxi-ss-des.c, > > sunxi-ss-aes.c, sunxi-ss-rng.c, sunxi-ss-common.c and sunxi-ss.h Does > > can I add a sunxi-ss directory in drivers/crypto ? > > Yes, I think a subdirectory would be best. Full ACK on this one. Use drivers/crypto/sunxi-ss/ . [...] Best regards, Marek Vasut -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
CMWQ workqueue questions
Hi, I was trying to understand the workqueues in more details: e.g. it is given kworker/u4:0 kworker/0:0 What does u4:0 represents and similarily 0:0 represents. I was glancing into the code when pool->cpu>0, there is u appended. Can you please explain u4:0 and 0:0 (what does it represent) in workqueue kworker? Regards, D. Raj-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] dt: Add DT bindings documentation for SUNXI Security System
On Thursday, May 22, 2014 at 05:09:54 PM, LABBE Corentin wrote: Missing commit message. Please fix this and send a V2. > Signed-off-by: LABBE Corentin > --- > Documentation/devicetree/bindings/crypto/sunxi-ss.txt | 9 + > 1 file changed, 9 insertions(+) > create mode 100644 Documentation/devicetree/bindings/crypto/sunxi-ss.txt > > diff --git a/Documentation/devicetree/bindings/crypto/sunxi-ss.txt > b/Documentation/devicetree/bindings/crypto/sunxi-ss.txt new file mode > 100644 > index 000..356563b > --- /dev/null > +++ b/Documentation/devicetree/bindings/crypto/sunxi-ss.txt > @@ -0,0 +1,9 @@ > +* Allwinner Security System found on A20 SoC > + > +Required properties: > +- compatible : Should be "allwinner,sun7i-a20-crypto". Why sun7i-a20 ? Is the crypto unit different in other sunxi chips ? Can that not be described by DT props ? > +- reg: Should contain the SS register location and length. SS? What is that? Fix this text to be actually descriptive please. > +- interrupts: Should contain the IRQ line for the SS. > +- clocks : A phandle to the functional clock node of the SS module > +- clock-names : Name of the functional clock, should be "ahb" and "mod". > + Best regards, Marek Vasut -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
CMWQ workqueue questions
Hi, I was trying to understand the workqueues in more details: e.g. it is given kworker/u4:0 kworker/0:0 What does u4:0 represents and similarily 0:0 represents. I was glancing into the code when pool->cpu>0, there is u appended. Can you please explain u4:0 and 0:0 (what does it represent) in workqueue kworker? Regards, D. Raj-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
CMWQ workqueue questions
Hi, I was trying to understand the workqueues in more details: e.g. it is given kworker/u4:0 kworker/0:0 What does u4:0 represents and similarily 0:0 represents. I was glancing into the code when pool->cpu>0, there is u appended. Can you please explain u4:0 and 0:0 (what does it represent) in workqueue kworker? Regards, D. Raj-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
CMWQ workqueue questions
Hi, I was trying to understand the workqueues in more details: e.g. it is given kworker/u4:0 kworker/0:0 What does u4:0 represents and similarily 0:0 represents. I was glancing into the code when pool->cpu>0, there is u appended. Can you please explain u4:0 and 0:0 (what does it represent) in workqueue kworker? Regards, D. Raj-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] crypto: Add Allwinner Security System crypto accelerator
On Thursday, May 22, 2014 at 05:09:56 PM, LABBE Corentin wrote:
Do I have to repeat myself ? :)
> Signed-off-by: LABBE Corentin
> ---
> drivers/crypto/Kconfig| 49 ++
> drivers/crypto/Makefile |1 +
> drivers/crypto/sunxi-ss.c | 1476
> + 3 files changed, 1526
> insertions(+)
> create mode 100644 drivers/crypto/sunxi-ss.c
>
> diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
> index 03ccdb0..5ea0922 100644
> --- a/drivers/crypto/Kconfig
> +++ b/drivers/crypto/Kconfig
> @@ -418,4 +418,53 @@ config CRYPTO_DEV_MXS_DCP
> To compile this driver as a module, choose M here: the module
> will be called mxs-dcp.
>
> +config CRYPTO_DEV_SUNXI_SS
> +tristate "Support for Allwinner Security System cryptographic
> accelerator" +depends on ARCH_SUNXI
> +help
> + Some Allwinner processors have a crypto accelerator named
> + Security System. Select this if you want to use it.
> +
> + To compile this driver as a module, choose M here: the module
> + will be called sunxi-ss.
> +
> +if CRYPTO_DEV_SUNXI_SS
> +config CRYPTO_DEV_SUNXI_SS_PRNG
> + bool "Security System PRNG"
> + select CRYPTO_RNG2
> + help
> + If you enable this option, the SS will provide a pseudo random
> + number generator.
> +config CRYPTO_DEV_SUNXI_SS_MD5
> + bool "Security System MD5"
> + select CRYPTO_MD5
> + help
> + If you enable this option, the SS will provide MD5 hardware
> + acceleration.
This is one IP block and it provides 5 algorithms. Put it under one config
option please.
Also, just shorted this to CONFIG_CRYPTO_SUNXI_SS , the _DEV stuff in the name
is useless.
[...]
> diff --git a/drivers/crypto/sunxi-ss.c b/drivers/crypto/sunxi-ss.c
> new file mode 100644
> index 000..bbf57bc
> --- /dev/null
> +++ b/drivers/crypto/sunxi-ss.c
> @@ -0,0 +1,1476 @@
> +/*
> + * sunxi-ss.c - hardware cryptographic accelerator for Allwinner A20 SoC
Why can this not be generic Allwinner-all-chips driver ? Does the IP block
change that dramatically between the chips?
[...]
> +#ifdef CONFIG_CRYPTO_DEV_SUNXI_SS_MD5
> +#include
> +#define SUNXI_SS_HASH_COMMON
> +#endif
> +#ifdef CONFIG_CRYPTO_DEV_SUNXI_SS_SHA1
> +#include
> +#define SUNXI_SS_HASH_COMMON
> +#endif
> +#ifdef SUNXI_SS_HASH_COMMON
> +#include
> +#include
> +#endif
> +#ifdef CONFIG_CRYPTO_DEV_SUNXI_SS_AES
> +#include
> +#endif
> +
> +#ifdef CONFIG_CRYPTO_DEV_SUNXI_SS_3DES
> +#define SUNXI_SS_DES
> +#endif
> +#ifdef CONFIG_CRYPTO_DEV_SUNXI_SS_DES
> +#define SUNXI_SS_DES
> +#endif
> +#ifdef SUNXI_SS_DES
> +#include
> +#endif
Please discard this mayhem when getting rid of all the configuration option.
> +#ifdef CONFIG_CRYPTO_DEV_SUNXI_SS_PRNG
> +#include
> +
> +struct prng_context {
> + u8 seed[192/8];
> + unsigned int slen;
> +};
> +#endif
> +
> +#define SUNXI_SS_CTL0x00
> +#define SUNXI_SS_KEY0 0x04
> +#define SUNXI_SS_KEY1 0x08
> +#define SUNXI_SS_KEY2 0x0C
> +#define SUNXI_SS_KEY3 0x10
> +#define SUNXI_SS_KEY4 0x14
> +#define SUNXI_SS_KEY5 0x18
> +#define SUNXI_SS_KEY6 0x1C
> +#define SUNXI_SS_KEY7 0x20
> +
> +#define SUNXI_SS_IV00x24
> +#define SUNXI_SS_IV10x28
> +#define SUNXI_SS_IV20x2C
> +#define SUNXI_SS_IV30x30
> +
> +#define SUNXI_SS_CNT0 0x34
> +#define SUNXI_SS_CNT1 0x38
> +#define SUNXI_SS_CNT2 0x3C
> +#define SUNXI_SS_CNT3 0x40
> +
> +#define SUNXI_SS_FCSR 0x44
> +#define SUNXI_SS_ICSR 0x48
> +
> +#define SUNXI_SS_MD00x4C
> +#define SUNXI_SS_MD10x50
> +#define SUNXI_SS_MD20x54
> +#define SUNXI_SS_MD30x58
> +#define SUNXI_SS_MD40x5C
> +
> +#define SS_RXFIFO 0x200
> +#define SS_TXFIFO 0x204
You don't have much consistency in the register naming scheme, please fix this
somehow. I suppose renaming the SS_[RT]XFIFO registers to SUNXI_SS_[RT]XFIFO is
a good idea.
> +/* SUNXI_SS_CTL configuration values */
> +
> +/* AES/DES/3DES key select - bits 24-27 */
> +#define SUNXI_SS_KEYSELECT_KEYN (0 << 24)
Uh oh , you ORR some values with this flag, which is always zero. This seems
broken.
[...]
> +/* SS Method - bits 4-6 */
> +#define SUNXI_OP_AES(0 << 4)
> +#define SUNXI_OP_DES(1 << 4)
> +#define SUNXI_OP_3DES (2 << 4)
> +#define SUNXI_OP_SHA1 (3 << 4)
> +#define SUNXI_OP_MD5(4 << 4)
> +#define SUNXI_OP_PRNG (5 << 4)
> +
> +/* Data end bit - bit 2 */
> +#define SUNXI_SS_DATA_END BIT(2)
Please use the BIT() macros in consistent fashion. Either use it or don't use
it
(I'd much rather see it not used), but don't mix the stuff :-(
[...]
> +/* General notes:
> + * I
Re: [PATCH] crypto: x86/sha1: fix coverity CID 1195603
On Thursday, May 08, 2014 at 03:30:25 PM, Herbert Xu wrote:
> On Wed, Apr 30, 2014 at 03:17:54PM -0400, Milos Vyletel wrote:
> > Coverity detected possible use of uninitialized pointer when printing
> > info message during module load. While this is higly unlikely to cause
> > any troubles simple change in sha1_ssse3_mod_init to make it look like
> > sha256/512 init function will fix this.
> >
> > 260
> >
> > 6. Condition sha1_transform_asm, taking true branch
> >
> > 261if (sha1_transform_asm) {
> >
> > CID 1195603 (#1 of 1): Uninitialized pointer read (UNINIT)
> > 7. uninit_use_in_call: Using uninitialized value algo_name when calling
> > printk. 262pr_info("Using %s optimized SHA-1
> > implementation\n", algo_name); 263return
> > crypto_register_shash();
> > 264}
> >
> > Reported-by:
> > Signed-off-by: Milos Vyletel
>
> Unless I'm missing something there is no way this code can use
> the variable without initialising it.
>
> So this is a false positive and I'm not applying this.
I suppose changing the commit message to "align the code with sha256 ... NOTE:
this also fixed CIDxyz." would work better and might get this applied ? I think
unification of code is always good.
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] ARM: sun7i: dt: Add Security System to A20 SoC DTS
On Thursday, May 22, 2014 at 05:09:55 PM, LABBE Corentin wrote:
Commit message ... damn, there is a reason why you _should_ write the commit
message, even if the $subject is descriptive enough. You should elaborate on
what you did here and _why_ you did it. The _why_ part is also really important
since when you read this patch 5 years from now, you won't be looking at this
in
a confused fashion.
> Signed-off-by: LABBE Corentin
> ---
> arch/arm/boot/dts/sun7i-a20.dtsi | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi
> b/arch/arm/boot/dts/sun7i-a20.dtsi index f4b00a5..ea56552 100644
> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> @@ -523,6 +523,14 @@
> status = "disabled";
> };
>
> + crypto: crypto-engine@01c15000 {
> + compatible = "allwinner,sun7i-a20-crypto";
> + reg = <0x01c15000 0x1000>;
> + interrupts = <0 86 4>;
> + clocks = <_gates 5>, <_clk>;
> + clock-names = "ahb", "mod";
> + };
> +
> spi2: spi@01c17000 {
> compatible = "allwinner,sun4i-a10-spi";
> reg = <0x01c17000 0x1000>;
Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 1/3] ARM: EXYNOS: Add support for EXYNOS5410 SoC
Hi Tarek,
On 24.05.2014 11:33, Tarek Dakhran wrote:
> Hi Tomasz
>
> I faced another problem, while changing this patch.
> See below.
>
> On 05/24/2014 01:11 AM, Tomasz Figa wrote:
>> Hi Tarek,
>>
>> With v2 of the series I mentioned in review of previous version [1],
>> this patch can be skipped.
>>
>> [1] http://www.spinics.net/lists/linux-samsung-soc/msg31258.html
>>
>> Best regards,
>> Tomasz
>>
>> On 23.05.2014 12:35, Tarek Dakhran wrote:
>>> EXYNOS5410 is SoC in Samsung's Exynos5 SoC series.
>>> Add initial support for this SoC.
>>>
>>> Signed-off-by: Tarek Dakhran
>>> Signed-off-by: Vyacheslav Tyrtov
>>> ---
>>> arch/arm/mach-exynos/Kconfig|8
>>> arch/arm/mach-exynos/common.h | 11 ++-
>>> arch/arm/mach-exynos/firmware.c |2 +-
>>> 3 files changed, 19 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
>>> index 1602abc..79a3e85 100644
>>> --- a/arch/arm/mach-exynos/Kconfig
>>> +++ b/arch/arm/mach-exynos/Kconfig
>>> @@ -84,6 +84,14 @@ config SOC_EXYNOS5250
>>> help
>>> Enable EXYNOS5250 SoC support
>>> +config SOC_EXYNOS5410
>>> +bool "SAMSUNG EXYNOS5410"
>>> +default y
>>> +depends on ARCH_EXYNOS5
>>> +select PM_GENERIC_DOMAINS if PM_RUNTIME
>>> +help
>>> + Enable EXYNOS5410 SoC support
>>> +
>>> config SOC_EXYNOS5420
>>> bool "SAMSUNG EXYNOS5420"
>>> default y
>>> diff --git a/arch/arm/mach-exynos/common.h
>>> b/arch/arm/mach-exynos/common.h
>>> index e2d0954..d64c6de 100644
>>> --- a/arch/arm/mach-exynos/common.h
>>> +++ b/arch/arm/mach-exynos/common.h
>>> @@ -21,6 +21,7 @@
>>> #define EXYNOS4_CPU_MASK0xFFFE
>>> #define EXYNOS5250_SOC_ID0x4352
>>> +#define EXYNOS5410_SOC_ID0xE541
>>> #define EXYNOS5420_SOC_ID0xE542
>>> #define EXYNOS5440_SOC_ID0xE544
>>> #define EXYNOS5_SOC_MASK0xF000
>>> @@ -37,6 +38,7 @@ IS_SAMSUNG_CPU(exynos4210, EXYNOS4210_CPU_ID,
>>> EXYNOS4_CPU_MASK)
>>> IS_SAMSUNG_CPU(exynos4212, EXYNOS4212_CPU_ID, EXYNOS4_CPU_MASK)
>>> IS_SAMSUNG_CPU(exynos4412, EXYNOS4412_CPU_ID, EXYNOS4_CPU_MASK)
>>> IS_SAMSUNG_CPU(exynos5250, EXYNOS5250_SOC_ID, EXYNOS5_SOC_MASK)
>>> +IS_SAMSUNG_CPU(exynos5410, EXYNOS5410_SOC_ID, EXYNOS5_SOC_MASK)
>>> IS_SAMSUNG_CPU(exynos5420, EXYNOS5420_SOC_ID, EXYNOS5_SOC_MASK)
>>> IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID, EXYNOS5_SOC_MASK)
>>> @@ -68,6 +70,12 @@ IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID,
>>> EXYNOS5_SOC_MASK)
>>> # define soc_is_exynos5250()0
>>> #endif
>>> +#if defined(CONFIG_SOC_EXYNOS5410)
>>> +# define soc_is_exynos5410()is_samsung_exynos5410()
>>> +#else
>>> +# define soc_is_exynos5410()0
>>> +#endif
>>> +
>>> #if defined(CONFIG_SOC_EXYNOS5420)
>>> # define soc_is_exynos5420()is_samsung_exynos5420()
>>> #else
>>> @@ -82,7 +90,8 @@ IS_SAMSUNG_CPU(exynos5440, EXYNOS5440_SOC_ID,
>>> EXYNOS5_SOC_MASK)
>>> #define soc_is_exynos4() (soc_is_exynos4210() ||
>>> soc_is_exynos4212() || \
>>> soc_is_exynos4412())
>>> -#define soc_is_exynos5() (soc_is_exynos5250() || soc_is_exynos5420())
>>> +#define soc_is_exynos5() (soc_is_exynos5250() || soc_is_exynos5410()
>>> || \
>>> + soc_is_exynos5420())
>>>
> This is the place where we need it.
> Or this macro should be changed (maybe read compatible property from dt).
>
The problem is in fact not here, but in code using this macro. Let's
see, what git grep[1] gives us:
> arch/arm/mach-exynos/exynos.c-static void __init exynos_map_io(void)
> arch/arm/mach-exynos/exynos.c-{
> arch/arm/mach-exynos/exynos.c- if (soc_is_exynos4())
> arch/arm/mach-exynos/exynos.c- iotable_init(exynos4_iodesc,
> ARRAY_SIZE(exynos4_iodesc));
> arch/arm/mach-exynos/exynos.c-
> arch/arm/mach-exynos/exynos.c: if (soc_is_exynos5())
> arch/arm/mach-exynos/exynos.c- iotable_init(exynos5_iodesc,
> ARRAY_SIZE(exynos5_iodesc));
OK, so we have an array of static mappings, which can't be handled using
DT yet. That would probably explain why it fails to boot.
> arch/arm/mach-exynos/exynos.c-}
> arch/arm/mach-exynos/exynos.c-static void __init exynos_dt_machine_init(void)
> arch/arm/mach-exynos/exynos.c-{
[snip]
> arch/arm/mach-exynos/exynos.c: if (soc_is_exynos5()) {
> arch/arm/mach-exynos/exynos.c- for_each_compatible_node(i2c_np,
> NULL, i2c_compat) {
> arch/arm/mach-exynos/exynos.c- if
> (of_device_is_available(i2c_np)) {
> arch/arm/mach-exynos/exynos.c- id =
> of_alias_get_id(i2c_np, "i2c");
> arch/arm/mach-exynos/exynos.c- if (id < 4) {
> arch/arm/mach-exynos/exynos.c- tmp =
> readl(EXYNOS5_SYS_I2C_CFG);
> arch/arm/mach-exynos/exynos.c- writel(tmp &
> ~(0x1 << id),
> arch/arm/mach-exynos/exynos.c-
> EXYNOS5_SYS_I2C_CFG);
>
[PATCH] rtc: add support of nvram for maxim dallas rtc ds1343
This is a patch to add support of nvram for maxim dallas
rtc ds1343
Signed-off-by: Raghavendra Chandra Ganiga
---
drivers/rtc/rtc-ds1343.c | 75 ++--
1 file changed, 73 insertions(+), 2 deletions(-)
diff --git a/drivers/rtc/rtc-ds1343.c b/drivers/rtc/rtc-ds1343.c
index c371918..ae9f997 100644
--- a/drivers/rtc/rtc-ds1343.c
+++ b/drivers/rtc/rtc-ds1343.c
@@ -4,6 +4,7 @@
* Real Time Clock
*
* Author : Raghavendra Chandra Ganiga
+ * Ankur Srivastava : DS1343 Nvram Support
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
@@ -45,6 +46,9 @@
#define DS1343_CONTROL_REG 0x0F
#define DS1343_STATUS_REG 0x10
#define DS1343_TRICKLE_REG 0x11
+#define DS1343_NVRAM 0x20
+
+#define DS1343_NVRAM_LEN 96
/* DS1343 Control Registers bits */
#define DS1343_EOSC0x80
@@ -149,6 +153,64 @@ static ssize_t ds1343_store_glitchfilter(struct device
*dev,
static DEVICE_ATTR(glitch_filter, S_IRUGO | S_IWUSR, ds1343_show_glitchfilter,
ds1343_store_glitchfilter);
+static ssize_t ds1343_nvram_write(struct file *filp, struct kobject *kobj,
+ struct bin_attribute *attr,
+ char *buf, loff_t off, size_t count)
+{
+ int ret;
+ unsigned char address;
+ struct device *dev = kobj_to_dev(kobj);
+ struct ds1343_priv *priv = dev_get_drvdata(dev);
+
+ if (unlikely(!count))
+ return count;
+
+ if ((count + off) > DS1343_NVRAM_LEN)
+ count = DS1343_NVRAM_LEN - off;
+
+ address = DS1343_NVRAM + off;
+
+ ret = regmap_bulk_write(priv->map, address, buf, count);
+ if (ret < 0)
+ dev_err(>spi->dev, "Error in nvram write %d", ret);
+
+ return (ret < 0) ? ret : count;
+}
+
+
+static ssize_t ds1343_nvram_read(struct file *filp, struct kobject *kobj,
+ struct bin_attribute *attr,
+ char *buf, loff_t off, size_t count)
+{
+ int ret;
+ unsigned char address;
+ struct device *dev = kobj_to_dev(kobj);
+ struct ds1343_priv *priv = dev_get_drvdata(dev);
+
+ if (unlikely(!count))
+ return count;
+
+ if ((count + off) > DS1343_NVRAM_LEN)
+ count = DS1343_NVRAM_LEN - off;
+
+ address = DS1343_NVRAM + off;
+
+ ret = regmap_bulk_read(priv->map, address, buf, count);
+ if (ret < 0)
+ dev_err(>spi->dev, "Error in nvram read %d\n", ret);
+
+ return (ret < 0) ? ret : count;
+}
+
+
+static struct bin_attribute nvram_attr = {
+ .attr.name = "nvram",
+ .attr.mode = S_IRUGO | S_IWUSR,
+ .read = ds1343_nvram_read,
+ .write = ds1343_nvram_write,
+ .size = DS1343_NVRAM_LEN,
+};
+
static ssize_t ds1343_show_alarmstatus(struct device *dev,
struct device_attribute *attr, char *buf)
{
@@ -274,12 +336,16 @@ static int ds1343_sysfs_register(struct device *dev)
if (err)
goto error1;
+ err = device_create_bin_file(dev, _attr);
+ if (err)
+ goto error2;
+
if (priv->irq <= 0)
return err;
err = device_create_file(dev, _attr_alarm_mode);
if (err)
- goto error2;
+ goto error3;
err = device_create_file(dev, _attr_alarm_status);
if (!err)
@@ -287,6 +353,9 @@ static int ds1343_sysfs_register(struct device *dev)
device_remove_file(dev, _attr_alarm_mode);
+error3:
+ device_remove_bin_file(dev, _attr);
+
error2:
device_remove_file(dev, _attr_trickle_charger);
@@ -302,6 +371,7 @@ static void ds1343_sysfs_unregister(struct device *dev)
device_remove_file(dev, _attr_glitch_filter);
device_remove_file(dev, _attr_trickle_charger);
+ device_remove_bin_file(dev, _attr);
if (priv->irq <= 0)
return;
@@ -684,6 +754,7 @@ static struct spi_driver ds1343_driver = {
module_spi_driver(ds1343_driver);
MODULE_DESCRIPTION("DS1343 RTC SPI Driver");
-MODULE_AUTHOR("Raghavendra Chandra Ganiga ");
+MODULE_AUTHOR("Raghavendra Chandra Ganiga ,"
+ "Ankur Srivastava ");
MODULE_LICENSE("GPL v2");
MODULE_VERSION(DS1343_DRV_VERSION);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: imx: introduce function imx_free_mx3_camera
Hello Uwe and Greg,
> You'd do a better deed if you picked up
> http://thread.gmane.org/gmane.linux.kernel/1613364/focus=1635995
Since there is nothing wrong with the last version of the patch in
the above thread, I feel strange about picking it up and just splitting
it into two patches. However it would be good to have it applied.
I think the reason why the author didn't resend is that the object file
and data structure layout information in the changelog depend on the
changes to both .name and .dma_mask and by splitting the patch this
information would not apply to any one of the resulting two patches.
Perhaps keeping this information in the changelog is a good reason for
applying the patch as it is?
(I have attached the patch in question)
Best regards,
Emil Goode
>From 66b72cb8eb71974903dd40ed67a34412faf818f0 Mon Sep 17 00:00:00 2001
From: Yann Droneaud
Date: Mon, 27 Jan 2014 11:05:52 +0100
Subject: [PATCH] driver core/platform: don't leak memory allocated for
dma_mask
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Since commit 01dcc60a7cb8, platform_device_register_full() is
available to allocate and register a platform device.
If a dma_mask is provided as part of platform_device_info,
platform_device_register_full() allocate memory for a u64 using
kmalloc().
A comment in the code state that "[t]his memory isn't freed when the
device is put".
It's never a good thing to leak memory, but there's only very few
users of platform_device_info's dma_mask, and those are mostly
"static" devices that are not going to be plugged/unplugged often.
So memory leak is not really an issue, but allocating 8 bytes through
kmalloc() seems overkill.
And it's a pity to have to allocate 8 bytes for the dma_mask while up
to 7 bytes are wasted at the end of struct platform_object in the form
of padding after name field: unfortunately this padding is not used
when allocating the memory to hold the name.
To address theses issues, this patch adds dma_mask to platform_object
struct so that it is always allocated for all struct platform_device
allocated through platform_device_alloc() or platform_device_register_full().
And since it's within struct platform_object, dma_mask won't be leaked
anymore when struct platform_device got released. Storage for dma_mask
is added almost for free by removing the padding at the end of struct
platform_object.
Padding at the end of the structure is removed by making name a C99
flexible array member (eg. a zero sized array). To handle this change,
memory allocation is updated to take care of allocating an additional
byte for the NUL terminating character.
No more memory leak, no small allocation, no byte wasted and
a slight reduction in code size.
Built on Fedora 20, using GCC 4.8, for ARM, i386, x86_64 and PPC64
architectures, the size of the object file and the data structure layout
are updated as follow, produced with commands:
$ size drivers/base/platform.o
$ pahole drivers/base/platform.o \
--recursive \
--class_name device,pdev_archdata,platform_device,platform_object
--- size+pahole.next-20140124
+++ size+pahole.next-20140124+
@@ -1,5 +1,5 @@
textdata bss dec hex filename
- 5616 472 32612017e8 obj-arm/drivers/base/platform.o
+ 5572 472 32607617bc obj-arm/drivers/base/platform.o
struct device {
struct device *parent; /* 0 4 */
struct device_private *p;/* 4 4 */
@@ -77,15 +77,15 @@ struct platform_object {
/* XXX last struct has 4 bytes of padding */
/* --- cacheline 6 boundary (384 bytes) --- */
-char name[1]; /* 384 1 */
+u64dma_mask; /* 384 8 */
+char name[0]; /* 392 0 */
-/* size: 392, cachelines: 7, members: 2 */
-/* padding: 7 */
+/* size: 392, cachelines: 7, members: 3 */
/* paddings: 1, sum paddings: 4 */
/* last cacheline: 8 bytes */
};
textdata bss dec hex filename
- 6007 532 32657119ab obj-i386/drivers/base/platform.o
+ 5943 532 326507196b obj-i386/drivers/base/platform.o
struct device {
struct device *parent; /* 0 4 */
struct device_private *p;/* 4 4 */
@@ -161,14 +161,14 @@ struct platform_device {
struct platform_object {
struct platform_device pdev; /* 0 392 */
/* --- cacheline 6 boundary (384 bytes) was 8 bytes ago --- */
-char name[1]; /* 392 1 */
+u64dma_mask; /* 392 8 */
+
Re: [PATCH RESEND v4 0/8] Add Allwinner A31 USB support
On Sat, May 24, 2014 at 07:19:40AM +0900, Greg Kroah-Hartman wrote: > On Fri, May 23, 2014 at 08:33:39PM +0200, Maxime Ripard wrote: > > Hi Greg, > > > > On Wed, May 14, 2014 at 06:05:20PM +0200, Greg Kroah-Hartman wrote: > > > On Wed, May 14, 2014 at 02:34:19PM +0200, Maxime Ripard wrote: > > > > On Tue, May 13, 2014 at 05:44:14PM +0200, Maxime Ripard wrote: > > > > > Hi everyone, > > > > > > > > > > This patchset adds support for the USB controllers found in the > > > > > Allwinner A31. > > > > > > > > > > While the design is similar to the earlier Allwinner SoCs that are > > > > > already supported, a few details here and there change, like the fact > > > > > that the PHYs now have one clock per phy, while it used to be only one > > > > > for all the PHYs. > > > > > > > > > > Resent adding Alan Stern's Acked-by and puting Greg KH in the > > > > > recipients this time... > > > > > > > > Applied patches 2, 7 and 8. > > > > > > Feel free to apply patches 5 and 6 to your tree, as your branch needs > > > these, with my: > > > > > > Acked-by: Greg Kroah-Hartman > > > > > > Or, if you want me to take them, just let me know and I will. > > > > It looks like it's still not in your tree (or at least, I haven't > > received the usual mail notifications). > > > > Is this expected? > > Given that I haven't applied any USB patches in a week or so, yes, it is > expected... > > Give me a week or so to catch up, I've been on the road for a month > now, and am finally home. Ok, thanks, I was just trying to make sure they weren't lost/forgotten. Maxime -- Maxime Ripard, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com signature.asc Description: Digital signature
Re: [PATCH] USB: cdc-acm: fix broken runtime suspend
On Mon, Apr 14, 2014 at 09:58:12PM +0200, Johan Hovold wrote: > The current ACM runtime-suspend implementation is broken in several > ways: > > Firstly, it buffers only the first write request being made while > suspended -- any further writes are silently dropped. > > Secondly, writes being dropped also leak write urbs, which are never > reclaimed (until the device is unbound). > > Thirdly, even the single buffered write is not cleared at shutdown > (which may happen before the device is resumed), something which can > lead to another urb leak as well as a PM usage-counter leak. > > Fix this by implementing a delayed-write queue using urb anchors and > making sure to discard the queue properly at shutdown. > > Reported-by: Xiao Jin > Signed-off-by: Johan Hovold Greg, I understand yoǘ're on your way home from Japan and are getting ready to work through the 3.16 patch queue. Could you please discard this one for now? I've found a couple of more PM related problems and I'll submit a slight update of this one as part of a larger series of fixes instead. Thanks, Johan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: android: describe use of memory barrier on sync.c
Added comments describing the purpose of using write memory
barrier in the context of sync_timeline_destory.
Signed-off-by: Niv Yehezkel
---
drivers/staging/android/sync.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 1f88c5d..18174f7 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -92,6 +92,10 @@ static void sync_timeline_free(struct kref *kref)
void sync_timeline_destroy(struct sync_timeline *obj)
{
obj->destroyed = true;
+ /*
+* Ensure timeline is marked as destroyed before
+* changing timeline's fences status.
+*/
smp_wmb();
/*
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpu/drm/ttm: Use mutex_lock_killable() for shrinker functions.
Hello.
I tried to test whether it is OK (from point of view of reentrant) to use
mutex_lock() or mutex_lock_killable() inside shrinker functions when shrinker
functions do memory allocation, for drivers/gpu/drm/ttm/ttm_page_alloc_dma.c is
doing memory allocation with mutex lock held inside ttm_dma_pool_shrink_scan().
If I compile a test module shown below which mimics extreme case of what
ttm_dma_pool_shrink_scan() will do
-- test.c start --
#include
#include
#include
#include
static DEFINE_MUTEX(lock);
static unsigned long shrink_test_count(struct shrinker *shrinker, struct
shrink_control *sc)
{
if (mutex_lock_killable()) {
printk(KERN_WARNING "Process %u (%s) gave up waiting for mutex"
"\n", current->pid, current->comm);
return 0;
}
mutex_unlock();
return 1;
}
static unsigned long shrink_test_scan(struct shrinker *shrinker, struct
shrink_control *sc)
{
LIST_HEAD(list);
int i = 0;
if (mutex_lock_killable()) {
printk(KERN_WARNING "Process %u (%s) gave up waiting for mutex"
"\n", current->pid, current->comm);
return 0;
}
while (1) {
struct list_head *l = kmalloc(PAGE_SIZE, sc->gfp_mask);
if (!l)
break;
list_add_tail(l, );
i++;
}
printk(KERN_WARNING "Process %u (%s) allocated %u pages\n",
current->pid, current->comm, i);
while (i--) {
struct list_head *l = list.next;
list_del(l);
kfree(l);
}
mutex_unlock();
return 1;
}
static struct shrinker recursive_shrinker = {
.count_objects = shrink_test_count,
.scan_objects = shrink_test_scan,
.seeks = DEFAULT_SEEKS,
};
static int __init recursive_shrinker_init(void)
{
register_shrinker(_shrinker);
return 0;
}
static void recursive_shrinker_exit(void)
{
unregister_shrinker(_shrinker);
}
module_init(recursive_shrinker_init);
module_exit(recursive_shrinker_exit);
MODULE_LICENSE("GPL");
-- test.c end --
and load the test module and do
# echo 3 > /proc/sys/vm/drop_caches
the system stalls with 0% CPU usage because of mutex deadlock
(with prior lockdep warning).
Is this because wrong gfp flags are passed to kmalloc() ? Is this because
the test module's shrinker functions return wrong values? Is this because
doing memory allocation with mutex held inside shrinker functions is
forbidden? Can anybody tell me what is wrong with my test module?
Regards.
[ 48.077353]
[ 48.077999] =
[ 48.080023] [ INFO: inconsistent lock state ]
[ 48.080023] 3.15.0-rc6-00190-g1ee1cea #203 Tainted: G OE
[ 48.080023] -
[ 48.080023] inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage.
[ 48.086745] kswapd0/784 [HC0[0]:SC0[0]:HE1:SE1] takes:
[ 48.086745] (lock#2){+.+.?.}, at: [] shrink_test_count+0x12/0x60
[test]
[ 48.086745] {RECLAIM_FS-ON-W} state was registered at:
[ 48.086745] [] mark_held_locks+0x68/0x90
[ 48.086745] [] lockdep_trace_alloc+0x9a/0xe0
[ 48.086745] [] kmem_cache_alloc+0x23/0x170
[ 48.086745] [] shrink_test_scan+0x3a/0xf90 [test]
[ 48.086745] [] shrink_slab_node+0x13e/0x1d0
[ 48.086745] [] shrink_slab+0x61/0xe0
[ 48.086745] [] drop_caches_sysctl_handler+0x69/0xf0
[ 48.086745] [] proc_sys_call_handler+0x6a/0xa0
[ 48.086745] [] proc_sys_write+0x1a/0x20
[ 48.086745] [] vfs_write+0xa0/0x190
[ 48.086745] [] SyS_write+0x56/0xc0
[ 48.086745] [] syscall_call+0x7/0xb
[ 48.086745] irq event stamp: 39
[ 48.086745] hardirqs last enabled at (39): []
count_shadow_nodes+0x20/0x40
[ 48.086745] hardirqs last disabled at (38): []
count_shadow_nodes+0xc/0x40
[ 48.086745] softirqs last enabled at (0): []
copy_process+0x2e7/0x1400
[ 48.086745] softirqs last disabled at (0): [< (null)>] (null)
[ 48.086745]
[ 48.086745] other info that might help us debug this:
[ 48.086745] Possible unsafe locking scenario:
[ 48.086745]
[ 48.086745]CPU0
[ 48.086745]
[ 48.086745] lock(lock#2);
[ 48.086745]
[ 48.086745] lock(lock#2);
[ 48.086745]
[ 48.086745] *** DEADLOCK ***
[ 48.086745]
[ 48.086745] 1 lock held by kswapd0/784:
[ 48.086745] #0: (shrinker_rwsem){.+}, at: []
shrink_slab+0x2a/0xe0
[ 48.086745]
[ 48.086745] stack backtrace:
[ 48.086745] CPU: 1 PID: 784 Comm: kswapd0 Tainted: G OE
3.15.0-rc6-00190-g1ee1cea #203
[ 48.086745] Hardware name: VMware, Inc. VMware Virtual Platform/440BX
Desktop Reference Platform, BIOS 6.00 08/15/2008
[ 48.086745] c1ab9c20 dd187c94 c151a48f dd184250 dd187cd0 c1088f33 c165aa02
c165ac9d
[ 48.086745] 0310
Re: [PATCH 02/10] xhci: 'noxhci_port_switch' kernel parameter
On Fri, May 23, 2014 at 11:39 PM, Holger Hans Peter Freyther wrote: > On Tue, May 20, 2014 at 03:40:16PM -0700, Dan Williams wrote: > > Dear Dan, > >> Sorry, I don't think it is fair to users to force them to re-compile >> their kernel to get their device to work. Granted, I'm new to USB >> development, but the rate of reports of endpoint devices that mess up >> and require quirks in the hcd-driver or usb-core seems un-ending to > > thank you very much for this statement. xhci-hcd is unusable for > many people. On my laptop I can't scan more than one document, the > laptop sometimes immediately wakes up after suspend and after almost > two years all of these issues remain. That's sad. We (Sarah, Mathias, and I) really want to fix that. > I am running kernels with a hacked up pci-quirks.c for months and > scanning documents work, suspend/resume is working, no issues with > USB serials. My job is not related to Linux kernel development so > I would love to go back to a distribution kernel. Please make this > possible. In the end "xhci" appears to be a "supported" driver? Yes, there are presently 3 people hacking on the xhci bug report backlog at Intel where it was just a solitary hero before. To be fair I believe the rate of discovery of non-spec compliant quirkiness is to blame. In the meantime, as we ramp to get back on top of the tidal wave of weird device interactions with xhci, I believe it is fair to offer a workaround. Let me see if I can achieve this with a debugfs interface so that 'noxhci_port_switch' does not become a permanent ABI per Greg's concern. -- Dan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] devfreq update for Linux 3.16
Dear Rafael,
Here goes the pull request of devfreq for 3.16
Cheers,
MyungJoo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The following changes since commit 4b660a7f5c8099d88d1a43d8ae138965112592c7:
Linux 3.15-rc6 (2014-05-22 06:42:02 +0900)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq.git tags/for-3.16
for you to fetch changes up to cb7063f453e543b97285a10343cfc02983d792ad:
PM / devfreq: remove checks for CONFIG_EXYNOS_ASV (2014-05-24 22:33:51 +0900)
-
Pull Request for Rafael.
Merge target is Linux 3.16
- - Clean up with modern macro in the core and drivers.
- - Fix incorrect error returns
- - Remove dead CONFIG check.
- - Fix resource leak in a driver.
-
Bartlomiej Zolnierkiewicz (3):
PM / devfreq: exynos4: introduce struct busfreq_ppmu_data
PM / devfreq: exynos5: introduce struct busfreq_ppmu_data
PM / devfreq: exynos: make more PPMU code common
Chanwoo Choi (11):
PM / devfreq: exynos4: Fix bug of resource leak and code clean on probe()
PM / devfreq: exynos4: Use SIMPLE_DEV_PM_OPS macro
PM / devfreq: exynos4: Add CONFIG_PM_OPP dependency to fix probe fail
PM / devfreq: exynos5: Use SIMPLE_DEV_PM_OPS macro
PM / devfreq: exynos5: Add CONFIG_PM_OPP dependency to fix probe fail
PM / devfreq: exynos4: use common PPMU code
PM / devfreq: Fix devfreq_remove_device() to improve the sequence ...
PM / devfreq: Add resource-managed function for devfreq device
PM / devfreq: Add devm_devfreq_{register,unregister}_opp_notfierfunction
PM / devfreq: exynos4: Use devm_devfreq_* function using device ...
PM / devfreq: exynos5: Use devm_devfreq_* function using device ...
Paul Bolle (1):
PM / devfreq: remove checks for CONFIG_EXYNOS_ASV
drivers/devfreq/Kconfig | 5 +-
drivers/devfreq/devfreq.c| 125 ++--
drivers/devfreq/exynos/Makefile | 2 +-
drivers/devfreq/exynos/exynos4_bus.c | 219 ++-
drivers/devfreq/exynos/exynos5_bus.c | 130 ++---
drivers/devfreq/exynos/exynos_ppmu.c | 60 ++
drivers/devfreq/exynos/exynos_ppmu.h | 8 ++
include/linux/devfreq.h | 35 +-
8 files changed, 317 insertions(+), 267 deletions(-)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.14 (GNU/Linux)
iQIcBAEBAgAGBQJTgKWPAAoJEDv/jgS9xknFYlMP/0zIsdDGxtJA3NdxJGT/dA+d
z7sDIBSOCQCBQv8CSMCY6HgtejgbtpRX8coKaSYGjLP9sL43hHCRkJesQdYNo5vE
xuU0Zo80ERBZvXj9pXC76ojmvBMRmynYPnbMC7ZgzGEFA2kSf/SoEAwSu6y+5uiF
b5igBp22QNd73V5c+Vjr6pzDfSXDyGDv5Km8jDFPvx3YLNChY471VtK+KMikGwGp
FplzfNSCThMPertAxKuWRlZMS8v0YVyO9TN4KHNQuwdGotiQcYweeAFL+G183ZaC
8m+komdIP2oct0h19j8298cGPQSH/NpCXTwXSFMhn/QEU6W3WtaTF3crURjhTxja
EZiSOClumMnZPJt6di10vV6TOS0e4pWgfP2ZX9sNRBYLf5Vs/P46kB3mzAM1LSeV
D/93dkv5mAoZPTt/eruB/4jOeQDewAtOf/o3/vOjXUu4QwQ7JARGUEZ8RKJktVHs
R5q7nrEFOckyoSME131ePODy5EUgYv2kFGmaLqwulZaUN7ooslBZiaph7Fc0f1VB
2TEQKLtbkPIYiDqTHF8MAkIjwzhuul02NpEN7UccHfc4RIkoyhNnOrhwsi2ktAJw
ID7x2ofVKvevHp2qiLWlAHAryEJ+aTYNpiDRByZiUWFrt8LlLIZuCkdxWYGWcyOY
dkeARTmbHnqfdYAeuTNn
=ZUxh
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] qla2xxx: remove stub qlt_check_srr_debug()
qlt_check_srr_debug() was added in v3.5. It is a stub function unless
CONFIG_QLA_TGT_DEBUG_SRR is defined. But CONFIG_QLA_TGT_DEBUG_SRR will
never be defined, because the Kconfig symbol QLA_TGT_DEBUG_SRR was never
added to the tree.
Signed-off-by: Paul Bolle
---
Compile tested.
Or was it intended for this to set it by hand? In that case: please drop
the CONFIG_ prefix, and, perhaps add a comment about its purpose.
drivers/scsi/qla2xxx/qla_target.c | 90 ---
1 file changed, 90 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_target.c
b/drivers/scsi/qla2xxx/qla_target.c
index 0cb73074c199..9729411faf45 100644
--- a/drivers/scsi/qla2xxx/qla_target.c
+++ b/drivers/scsi/qla2xxx/qla_target.c
@@ -1747,95 +1747,6 @@ static inline int qlt_need_explicit_conf(struct
qla_hw_data *ha,
cmd->conf_compl_supported;
}
-#ifdef CONFIG_QLA_TGT_DEBUG_SRR
-/*
- * Original taken from the XFS code
- */
-static unsigned long qlt_srr_random(void)
-{
- static int Inited;
- static unsigned long RandomValue;
- static DEFINE_SPINLOCK(lock);
- /* cycles pseudo-randomly through all values between 1 and 2^31 - 2 */
- register long rv;
- register long lo;
- register long hi;
- unsigned long flags;
-
- spin_lock_irqsave(, flags);
- if (!Inited) {
- RandomValue = jiffies;
- Inited = 1;
- }
- rv = RandomValue;
- hi = rv / 127773;
- lo = rv % 127773;
- rv = 16807 * lo - 2836 * hi;
- if (rv <= 0)
- rv += 2147483647;
- RandomValue = rv;
- spin_unlock_irqrestore(, flags);
- return rv;
-}
-
-static void qlt_check_srr_debug(struct qla_tgt_cmd *cmd, int *xmit_type)
-{
-#if 0 /* This is not a real status packets lost, so it won't lead to SRR */
- if ((*xmit_type & QLA_TGT_XMIT_STATUS) && (qlt_srr_random() % 200)
- == 50) {
- *xmit_type &= ~QLA_TGT_XMIT_STATUS;
- ql_dbg(ql_dbg_tgt_mgt, cmd->vha, 0xf015,
- "Dropping cmd %p (tag %d) status", cmd, cmd->tag);
- }
-#endif
- /*
-* It's currently not possible to simulate SRRs for FCP_WRITE without
-* a physical link layer failure, so don't even try here..
-*/
- if (cmd->dma_data_direction != DMA_FROM_DEVICE)
- return;
-
- if (qlt_has_data(cmd) && (cmd->sg_cnt > 1) &&
- ((qlt_srr_random() % 100) == 20)) {
- int i, leave = 0;
- unsigned int tot_len = 0;
-
- while (leave == 0)
- leave = qlt_srr_random() % cmd->sg_cnt;
-
- for (i = 0; i < leave; i++)
- tot_len += cmd->sg[i].length;
-
- ql_dbg(ql_dbg_tgt_mgt, cmd->vha, 0xf016,
- "Cutting cmd %p (tag %d) buffer"
- " tail to len %d, sg_cnt %d (cmd->bufflen %d,"
- " cmd->sg_cnt %d)", cmd, cmd->tag, tot_len, leave,
- cmd->bufflen, cmd->sg_cnt);
-
- cmd->bufflen = tot_len;
- cmd->sg_cnt = leave;
- }
-
- if (qlt_has_data(cmd) && ((qlt_srr_random() % 100) == 70)) {
- unsigned int offset = qlt_srr_random() % cmd->bufflen;
-
- ql_dbg(ql_dbg_tgt_mgt, cmd->vha, 0xf017,
- "Cutting cmd %p (tag %d) buffer head "
- "to offset %d (cmd->bufflen %d)", cmd, cmd->tag, offset,
- cmd->bufflen);
- if (offset == 0)
- *xmit_type &= ~QLA_TGT_XMIT_DATA;
- else if (qlt_set_data_offset(cmd, offset)) {
- ql_dbg(ql_dbg_tgt_mgt, cmd->vha, 0xf018,
- "qlt_set_data_offset() failed (tag %d)", cmd->tag);
- }
- }
-}
-#else
-static inline void qlt_check_srr_debug(struct qla_tgt_cmd *cmd, int *xmit_type)
-{}
-#endif
-
static void qlt_24xx_init_ctio_to_isp(struct ctio7_to_24xx *ctio,
struct qla_tgt_prm *prm)
{
@@ -1918,7 +1829,6 @@ int qlt_xmit_response(struct qla_tgt_cmd *cmd, int
xmit_type,
int res;
memset(, 0, sizeof(prm));
- qlt_check_srr_debug(cmd, _type);
ql_dbg(ql_dbg_tgt, cmd->vha, 0xe018,
"is_send_status=%d, cmd->bufflen=%d, cmd->sg_cnt=%d, "
--
1.9.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mm/process_vm_access: move into ipc/
"CROSS_MEMORY_ATTACH" and mm/process_vm_access.c seems misnamed and misplaced.
Actually it's a kind of IPC and it has no more relation to MM than sys_read().
This patch moves code into ipc/ and config option into init/Kconfig.
Signed-off-by: Konstantin Khlebnikov
---
init/Kconfig| 10 +
ipc/Makefile|1
ipc/process_vm_access.c | 383 +++
mm/Kconfig | 10 -
mm/Makefile |4
mm/process_vm_access.c | 383 ---
6 files changed, 394 insertions(+), 397 deletions(-)
create mode 100644 ipc/process_vm_access.c
delete mode 100644 mm/process_vm_access.c
diff --git a/init/Kconfig b/init/Kconfig
index 9d3585b..d6ddb7a 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -261,6 +261,16 @@ config POSIX_MQUEUE_SYSCTL
depends on SYSCTL
default y
+config CROSS_MEMORY_ATTACH
+ bool "Enable process_vm_readv/writev syscalls"
+ depends on MMU
+ default y
+ help
+ Enabling this option adds the system calls process_vm_readv and
+ process_vm_writev which allow a process with the correct privileges
+ to directly read from or write to to another process's address space.
+ See the man page for more details.
+
config FHANDLE
bool "open by fhandle syscalls"
select EXPORTFS
diff --git a/ipc/Makefile b/ipc/Makefile
index 9075e17..6982d3e 100644
--- a/ipc/Makefile
+++ b/ipc/Makefile
@@ -9,4 +9,5 @@ obj_mq-$(CONFIG_COMPAT) += compat_mq.o
obj-$(CONFIG_POSIX_MQUEUE) += mqueue.o msgutil.o $(obj_mq-y)
obj-$(CONFIG_IPC_NS) += namespace.o
obj-$(CONFIG_POSIX_MQUEUE_SYSCTL) += mq_sysctl.o
+obj-$(CONFIG_CROSS_MEMORY_ATTACH) += process_vm_access.o
diff --git a/ipc/process_vm_access.c b/ipc/process_vm_access.c
new file mode 100644
index 000..65aacea
--- /dev/null
+++ b/ipc/process_vm_access.c
@@ -0,0 +1,383 @@
+/*
+ * linux/ipc/process_vm_access.c
+ *
+ * Copyright (C) 2010-2011 Christopher Yeoh , IBM Corp.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#ifdef CONFIG_COMPAT
+#include
+#endif
+
+/**
+ * process_vm_rw_pages - read/write pages from task specified
+ * @pages: array of pointers to pages we want to copy
+ * @start_offset: offset in page to start copying from/to
+ * @len: number of bytes to copy
+ * @iter: where to copy to/from locally
+ * @vm_write: 0 means copy from, 1 means copy to
+ * Returns 0 on success, error code otherwise
+ */
+static int process_vm_rw_pages(struct page **pages,
+ unsigned offset,
+ size_t len,
+ struct iov_iter *iter,
+ int vm_write)
+{
+ /* Do the copy for each page */
+ while (len && iov_iter_count(iter)) {
+ struct page *page = *pages++;
+ size_t copy = PAGE_SIZE - offset;
+ size_t copied;
+
+ if (copy > len)
+ copy = len;
+
+ if (vm_write) {
+ if (copy > iov_iter_count(iter))
+ copy = iov_iter_count(iter);
+ copied = iov_iter_copy_from_user(page, iter,
+ offset, copy);
+ iov_iter_advance(iter, copied);
+ set_page_dirty_lock(page);
+ } else {
+ copied = copy_page_to_iter(page, offset, copy, iter);
+ }
+ len -= copied;
+ if (copied < copy && iov_iter_count(iter))
+ return -EFAULT;
+ offset = 0;
+ }
+ return 0;
+}
+
+/* Maximum number of pages kmalloc'd to hold struct page's during copy */
+#define PVM_MAX_KMALLOC_PAGES (PAGE_SIZE * 2)
+
+/**
+ * process_vm_rw_single_vec - read/write pages from task specified
+ * @addr: start memory address of target process
+ * @len: size of area to copy to/from
+ * @iter: where to copy to/from locally
+ * @process_pages: struct pages area that can store at least
+ * nr_pages_to_copy struct page pointers
+ * @mm: mm for task
+ * @task: task to read/write from
+ * @vm_write: 0 means copy from, 1 means copy to
+ * Returns 0 on success or on failure error code
+ */
+static int process_vm_rw_single_vec(unsigned long addr,
+ unsigned long len,
+ struct iov_iter *iter,
+ struct page **process_pages,
+ struct mm_struct *mm,
+ struct task_struct *task,
+
[PATCH 1/1] Staging: dgap: Fixed iomem accesses in dgap.c
I changed dereferences from iomem into the adequate ioread function. Signed-off-by: Pascal COMBES --- NB: -I didn't replace the old style ioread[bwl] by their newer equivalents (ioread[8/16/32]). Is it worth? -I did this for task 16 of the eudyptula challenge. diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c index d7cfc45..fe16da8 100644 --- a/drivers/staging/dgap/dgap.c +++ b/drivers/staging/dgap/dgap.c @@ -1412,8 +1412,8 @@ static int dgap_tty_init(struct board_t *brd) ch->ch_dsr = DM_DSR; } - ch->ch_taddr = vaddr + ((ch->ch_bs->tx_seg) << 4); - ch->ch_raddr = vaddr + ((ch->ch_bs->rx_seg) << 4); + ch->ch_taddr = vaddr + (ioread16(&(ch->ch_bs->tx_seg)) << 4); + ch->ch_raddr = vaddr + (ioread16(&(ch->ch_bs->rx_seg)) << 4); ch->ch_tx_win = 0; ch->ch_rx_win = 0; ch->ch_tsize = readw(&(ch->ch_bs->tx_max)) + 1; @@ -5084,8 +5084,8 @@ static uint dgap_get_custom_baud(struct channel_t *ch) * Go get from fep mem, what the fep * believes the custom baud rate is. */ - offset = *(unsigned short __iomem *)(vaddr + ECS_SEG)) << 4) + - (ch->ch_portnum * 0x28) + LINE_SPEED)); + offset = (ioread16(vaddr + ECS_SEG) << 4) + (ch->ch_portnum * 0x28) + + LINE_SPEED; value = readw(vaddr + offset); return value; @@ -5633,10 +5633,10 @@ static int dgap_event(struct board_t *bd) event = bd->re_map_membase + tail + EVSTART; - port = event[0]; - reason = event[1]; - modem = event[2]; - b1 = event[3]; + port = ioread8(event); + reason = ioread8(event + 1); + modem = ioread8(event + 2); + b1 = ioread8(event + 3); /* * Make sure the interrupt is valid. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] SCSI fixes for 3.15-rc6
This is a single fix for a bug exposed by a sysfs change in 3.13 which now causes libsas to trigger a warn on in device removal. The patch is available here: git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes The short changelog is: Joe Lawrence (1): scsi_transport_sas: move bsg destructor into sas_rphy_remove And the diffstat: drivers/scsi/scsi_transport_sas.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) With full diff below. James --- diff --git a/drivers/scsi/scsi_transport_sas.c b/drivers/scsi/scsi_transport_sas.c index 1b68142..c341f85 100644 --- a/drivers/scsi/scsi_transport_sas.c +++ b/drivers/scsi/scsi_transport_sas.c @@ -1621,8 +1621,6 @@ void sas_rphy_free(struct sas_rphy *rphy) list_del(>list); mutex_unlock(_host->lock); - sas_bsg_remove(shost, rphy); - transport_destroy_device(dev); put_device(dev); @@ -1681,6 +1679,7 @@ sas_rphy_remove(struct sas_rphy *rphy) } sas_rphy_unlink(rphy); + sas_bsg_remove(NULL, rphy); transport_remove_device(dev); device_del(dev); } -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH RFC] proc/pid/mem: implement SEEK_DATA and SEEK_HOLE
lseek(fd, addr, SEEK_DATA) adjust file offset to the start address of next VMA,
or to addr if this address is allocated.
lseek(fd, addr, SEEK_HOLE) adjust file offset to the end address of VMA which
addr belongs to, or to addr itself if there is hole.
This way SEEK_HOLE reports a virtual zero-length hole between each contiguous
VMAs. This hack seems completely legit and allows to simplify implementation
(there is no function for finding next hole in VMAs' tree, walking along
->vm_next might be expensive) This also gives more information about layout.
Signed-off-by: Konstantin Khlebnikov
---
I have no practical use for this, just found this interesting.
---
fs/proc/base.c | 31 +--
1 file changed, 29 insertions(+), 2 deletions(-)
diff --git a/fs/proc/base.c b/fs/proc/base.c
index 2d696b0..aba4b47 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -769,13 +769,40 @@ static ssize_t mem_write(struct file *file, const char
__user *buf,
loff_t mem_lseek(struct file *file, loff_t offset, int orig)
{
+ struct mm_struct *mm = file->private_data;
+ struct vm_area_struct *vma;
+
switch (orig) {
- case 0:
+ case SEEK_SET:
file->f_pos = offset;
break;
- case 1:
+ case SEEK_CUR:
file->f_pos += offset;
break;
+ case SEEK_DATA:
+ case SEEK_HOLE:
+ if (!mm || !atomic_inc_not_zero(>mm_users))
+ return -ENXIO;
+ down_read(>mmap_sem);
+ vma = find_vma(mm, offset);
+ if (vma) {
+ if (orig == SEEK_DATA) {
+ if (offset >= vma->vm_start)
+ file->f_pos = offset;
+ else
+ file->f_pos = vma->vm_start;
+ } else {
+ if (offset < vma->vm_start)
+ file->f_pos = offset;
+ else
+ file->f_pos = vma->vm_end;
+ }
+ }
+ up_read(>mmap_sem);
+ mmput(mm);
+ if (!vma)
+ return -ENXIO;
+ break;
default:
return -EINVAL;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Váženie E-mail užívateľa;
Váženie E-mail užívateľa; Prekročili ste limit 23432 ukladanie na Váš e-mailovej schránky stanovenej vaše WEB SERVICE / správcu, a budete mať problémy pri odosielaní a prijímať e-maily, kým sa znova potvrdí svoju e-mailovú adresu. Potrebné postupy sú boli predložené nižšie vášho názoru, overte kliknutím na nižšie odkaz a vyplňte informácie na overenie vašej e-mailovú adresu. Prosím, kliknite tu http://updattwsd.jigsy.com/ Ak chcete zvýšiť svoju e-mailovú kvótu Vášho e-mailu. Varovanie! Ak tak neurobíte, bude mať k obmedzenému prístupu k poštovej schránke. zlyhanie aktualizovať svoj účet do troch dní od tejto aktualizácii oznámenia, váš účet bude natrvalo uzavretá. S pozdravom, Administrator System ® -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] acornscsi: remove linked command support
On Sat, 2014-05-24 at 16:13 +0400, James Bottomley wrote: > Wait, no, that's not a good idea. We leave obsolete drivers to bitrot. > Particularly we try not to touch them unless we have to because there > might be a few people still using them and the more we tamper, the > greater the risk that something gets broken. Which is also a way to notice whether people still use those obsolete drivers. > On that principle, since > there's no real reason to remove the code, (Unless one carries the hope that any check, treewide, for a CONFIG_* macro can be linked to a proper Kconfig symbol.) > it should stay ... until the > whole driver bitrots to the extent that we can no-longer compile it. I've run into this depreciation policy before. With aic7xxx_old (which I eventually convinced Fedora to disable, a few relases before it was removed from the tree). With aic94xx (which I also convinced Fedora to disable). I also tried multiple times to shut up advansys' compile time[1]. It seems SCSI might risk not to notice their bitrot, because eventually everybody stops compiling these obsolete drivers, leaving SCSI without feedback on their state. Anyhow, SCSI seems to be the only subsystem that uses this subcategory of not-really-maintained drivers. Other subsystems appear to allow anything to be fixed, even trivialities, which are what I tend to fix, and only stop allowing fixes if the drivers involved are going to be removed anyway. But maybe I just never ran into that category in other subsystems. > However, I'll do this if the Maintainer (rmk) acks ... because if it > breaks he gets to fix it. Paul Bolle [1] advansys prints a pointless compile time warning, on purpose. Clearly no one cares about its "wide board" support, but for some reason that warning needs to stay in. (Fedora declined to disable that driver.) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] lib/debugobjects.c: code clean-up
Fix some checkpatch warnings.
Cc: Josh Triplett
Cc: Andrew Morton
Signed-off-by: Fabian Frederick
---
lib/debugobjects.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/lib/debugobjects.c b/lib/debugobjects.c
index 437a6b4..69f25bf 100644
--- a/lib/debugobjects.c
+++ b/lib/debugobjects.c
@@ -271,7 +271,7 @@ static void debug_print_object(struct debug_obj *obj, char
*msg)
*/
static int
debug_object_fixup(int (*fixup)(void *addr, enum debug_obj_state state),
- void * addr, enum debug_obj_state state)
+ void *addr, enum debug_obj_state state)
{
int fixed = 0;
@@ -415,7 +415,8 @@ int debug_object_activate(void *addr, struct
debug_obj_descr *descr)
debug_print_object(obj, "activate");
state = obj->state;
raw_spin_unlock_irqrestore(>lock, flags);
- ret = debug_object_fixup(descr->fixup_activate, addr,
state);
+ ret = debug_object_fixup(descr->fixup_activate,
+addr, state);
return ret ? -EINVAL : 0;
case ODEBUG_STATE_DESTROYED:
@@ -680,7 +681,7 @@ static void __debug_check_no_obj_freed(const void *address,
unsigned long size)
chunks = ((eaddr - paddr) + (ODEBUG_CHUNK_SIZE - 1));
chunks >>= ODEBUG_CHUNK_SHIFT;
- for (;chunks > 0; chunks--, paddr += ODEBUG_CHUNK_SIZE) {
+ for (; chunks > 0; chunks--, paddr += ODEBUG_CHUNK_SIZE) {
db = get_bucket(paddr);
repeat:
@@ -1084,7 +1085,7 @@ void __init debug_objects_mem_init(void)
return;
obj_cache = kmem_cache_create("debug_objects_cache",
- sizeof (struct debug_obj), 0,
+ sizeof(struct debug_obj), 0,
SLAB_DEBUG_OBJECTS, NULL);
if (!obj_cache || debug_objects_replace_static_objects()) {
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] lib/debugobjects.c: add pr_fmt to logging
Add ODEBUG: prefix to pr_fmt
Cc: Josh Triplett
Cc: Andrew Morton
Signed-off-by: Fabian Frederick
---
lib/debugobjects.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/lib/debugobjects.c b/lib/debugobjects.c
index ea4c737..b628247 100644
--- a/lib/debugobjects.c
+++ b/lib/debugobjects.c
@@ -7,6 +7,9 @@
*
* For licencing details see kernel-base/COPYING
*/
+
+#define pr_fmt(fmt) "ODEBUG: " fmt
+
#include
#include
#include
@@ -218,7 +221,7 @@ static void debug_objects_oom(void)
unsigned long flags;
int i;
- pr_warn("ODEBUG: Out of memory. ODEBUG disabled\n");
+ pr_warn("Out of memory. ODEBUG disabled\n");
for (i = 0; i < ODEBUG_HASH_SIZE; i++, db++) {
raw_spin_lock_irqsave(>lock, flags);
@@ -292,9 +295,9 @@ static void debug_object_is_on_stack(void *addr, int
onstack)
limit++;
if (is_on_stack)
- pr_warn("ODEBUG: object is on stack, but not annotated\n");
+ pr_warn("object is on stack, but not annotated\n");
else
- pr_warn("ODEBUG: object is not on stack, but annotated\n");
+ pr_warn("object is not on stack, but annotated\n");
WARN_ON(1);
}
@@ -983,7 +986,7 @@ static void __init debug_objects_selftest(void)
if (check_results(, ODEBUG_STATE_NONE, ++fixups, ++warnings))
goto out;
#endif
- pr_info("ODEBUG: selftest passed\n");
+ pr_info("selftest passed\n");
out:
debug_objects_fixups = oldfixups;
@@ -1088,7 +1091,7 @@ void __init debug_objects_mem_init(void)
debug_objects_enabled = 0;
if (obj_cache)
kmem_cache_destroy(obj_cache);
- pr_warn("ODEBUG: out of memory.\n");
+ pr_warn("out of memory.\n");
} else
debug_objects_selftest();
}
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] lib/debugobjects.c: move __initdata after name
Cc: Josh Triplett
Cc: Andrew Morton
Signed-off-by: Fabian Frederick
---
lib/debugobjects.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/debugobjects.c b/lib/debugobjects.c
index b628247..437a6b4 100644
--- a/lib/debugobjects.c
+++ b/lib/debugobjects.c
@@ -791,7 +791,7 @@ struct self_test {
unsigned long dummy2[3];
};
-static __initdata struct debug_obj_descr descr_type_test;
+static struct debug_obj_descr descr_type_test __initdata;
/*
* fixup_init is called when:
@@ -915,7 +915,7 @@ out:
return res;
}
-static __initdata struct debug_obj_descr descr_type_test = {
+static struct debug_obj_descr descr_type_test __initdata = {
.name = "selftest",
.fixup_init = fixup_init,
.fixup_activate = fixup_activate,
@@ -923,7 +923,7 @@ static __initdata struct debug_obj_descr descr_type_test = {
.fixup_free = fixup_free,
};
-static __initdata struct self_test obj = { .static_init = 0 };
+static struct self_test obj __initdata = { .static_init = 0 };
static void __init debug_objects_selftest(void)
{
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] lib/debugobjects.c: convert printk to pr_foo()
Convert all except KERN_DEBUG
Cc: Josh Triplett
Cc: Andrew Morton
Signed-off-by: Fabian Frederick
---
lib/debugobjects.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/lib/debugobjects.c b/lib/debugobjects.c
index e0731c3..ea4c737 100644
--- a/lib/debugobjects.c
+++ b/lib/debugobjects.c
@@ -218,7 +218,7 @@ static void debug_objects_oom(void)
unsigned long flags;
int i;
- printk(KERN_WARNING "ODEBUG: Out of memory. ODEBUG disabled\n");
+ pr_warn("ODEBUG: Out of memory. ODEBUG disabled\n");
for (i = 0; i < ODEBUG_HASH_SIZE; i++, db++) {
raw_spin_lock_irqsave(>lock, flags);
@@ -292,11 +292,9 @@ static void debug_object_is_on_stack(void *addr, int
onstack)
limit++;
if (is_on_stack)
- printk(KERN_WARNING
- "ODEBUG: object is on stack, but not annotated\n");
+ pr_warn("ODEBUG: object is on stack, but not annotated\n");
else
- printk(KERN_WARNING
- "ODEBUG: object is not on stack, but annotated\n");
+ pr_warn("ODEBUG: object is not on stack, but annotated\n");
WARN_ON(1);
}
@@ -985,7 +983,7 @@ static void __init debug_objects_selftest(void)
if (check_results(, ODEBUG_STATE_NONE, ++fixups, ++warnings))
goto out;
#endif
- printk(KERN_INFO "ODEBUG: selftest passed\n");
+ pr_info("ODEBUG: selftest passed\n");
out:
debug_objects_fixups = oldfixups;
@@ -1090,7 +1088,7 @@ void __init debug_objects_mem_init(void)
debug_objects_enabled = 0;
if (obj_cache)
kmem_cache_destroy(obj_cache);
- printk(KERN_WARNING "ODEBUG: out of memory.\n");
+ pr_warn("ODEBUG: out of memory.\n");
} else
debug_objects_selftest();
}
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V3 1/8] cpufreq: cpufreq-cpu0: remove dependency on thermal
On Fri 2014-05-23 10:03:27, Viresh Kumar wrote: > On 22 May 2014 20:22, Eduardo Valentin wrote: > > However, on CPUs that needs thermal managment, it makes sense to have > > such dependency, from functional perspective. Mainly because scaling > > frequency and voltage up would be allowed only when thermal management > > is enabled. > > AFAIK, dependencies in KCONFIG are only for fixing compilation time issues. I do not think that's correct. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/4] devicetree: bindings: Properly document micrel ks8851 SPI chips
On Fri, May 23, 2014 at 12:57:17PM -0700, Stephen Boyd wrote: > Optional properties: > -- vdd-supply:supply for Ethernet mac > +- vdd-supply: analog 3.3V supply for Ethernet mac > +- vdd-io-supply: digital 1.8V IO supply for Ethernet mac So, according to the datasheet I managed to find this device has a supply VDD_IO (so normally written vdd-io-supply here), some other supplies which are tied to VDD_IO (so can probably be omitted) and a supply VDD_A3.3 none of which are optional. There is an internal regulator which can be used to drop a higher voltage VDD_IO down for some of the supplies tied to it but that's essentially a noop from software as far as I can tell. None of these supplies are obviously optional, though I've not read the datasheet in detail so I may have missed something here. That said it looks like this is intended to be a supply for an external PHY rather than the device itself, but even so my original question about it being able to operate without power still applies. Looking at the code it's certainly not doing any of the handling of a missing supply that I would associate with using _optional(). signature.asc Description: Digital signature
Re: [PATCH 20/51] Input: atmel_mxt_ts - Set default irqflags when there is no pdata
Yufeng Shen wrote: > On Thu, May 22, 2014 at 10:29 AM, Nick Dyer wrote: >> Dmitry Torokhov wrote: > Make the irqflags default to be IRQF_TRIGGER_FALLING if no platform data > is > provided. >>> >>> I think if there is no platform data we should use 0 as IRQ falgs and >>> assume that IRQ line is properly configured by the board code or via >>> device tree. >> >> Benson/Yufeng - do you still have a requirement to probe without platform >> data or device tree? I'm just merging in some changes to add device tree >> support, and it would simplify things a bit if I can drop this patch. > > It has been working for quite a while for boards/devices that don't > provide platform data. If we drop the default IRQ flags, sure we can add > code for each board to configure the IRQ separately, but that's just > adding extra work. Is there strong reason why we should not do the > default setting in the driver if it is not already configured in > platform data? OK, I will keep it in my tree for the moment, since you are using it. The reason I checked is that in general, I would like to be conservative about what is pushed upstream, because it will need maintaining for a long time. The other reason is that in fact Atmel recommend IRQF_TRIGGER_LOW for these chips, not IRQF_TRIGGER_FALLING, so there is a bit of an inconsistency here. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PM / devfreq: remove checks for CONFIG_EXYNOS_ASV
On Fri, May 23, 2014 at 1:52 PM, MyungJoo Ham wrote: > On Thu, May 22, 2014 at 5:37 AM, Paul Bolle wrote: >> Checks for CONFIG_EXYNOS_ASV were added in v3.3. But the related Kconfig >> symbol has never been added to the tree. Remove these checks, as they >> always evaluate to false. >> >> Signed-off-by: Paul Bolle > > Thanks for pointing this out. > > ASV was supposed to be merged, but it appears it failed or never attempted. > > I will merge with the next batch (this week). > > > Cheers, > MyungJoo. Uh.. ASV itself affects the power efficiency; thus, I'd like to keep it alive, but not as the current form. For 3.16, I'll correct the name following your report. (not going for 3.15RCx anyway) Then, I'll let it merged into struct busfreq_data for later RCx. Cheers, MyungJoo. > >> --- >> 0) Untested. >> >> 1) I do not really care much for this patch. Two years is not very long >> for dead code to remain in the tree. There is, however, a trivial issue >> that makes this patch stand out from the other patches in my current >> sweep of the tree for Kconfig related problems. >> >> See, here the use of an unknown Kconfig macro hides an obvious typo: it >> should either be "exynos_result_of_asv" or "exynos4_result_of_asv", but >> not both. Ie, this almost certainly wouldn't have compiled even if the >> Kconfig symbol EXYNOS_ASV would have been part of the tree. >> >> 2) So this makes me wonder whether there are any guidelines for using >> Kconfig macros before the related Kconfig symbols are merged? >> >> drivers/devfreq/Kconfig | 3 +-- >> drivers/devfreq/exynos/exynos4_bus.c | 13 - >> 2 files changed, 1 insertion(+), 15 deletions(-) -- MyungJoo Ham, Ph.D. System S/W Lab, S/W Center, Samsung Electronics -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: inotify, new idea?
Am 24.05.2014 09:52, schrieb Michael Kerrisk (man-pages): > On 04/21/2014 10:42 AM, Richard Weinberger wrote: >> Am 21.04.2014 09:24, schrieb Michael Kerrisk: Does recursive monitoring even work with inotify? Last time I've tried it did failed as soon I did a mkdir -p a/b/c/d because mkdir() raced against the thread which installes the new watches. >>> >>> As I understand it, you have to program to deal with the races (rescan >>> directories after adding watches). I recently did a lot of work >>> updating the inotify(7) man page to discuss all the issues that I know >>> of, and their remedies. If I missed anything, I'd appreciate a note on >>> it, so that it can be added. See >>> http://man7.org/linux/man-pages/man7/inotify.7.html#NOTES >> >> I'm aware of the rescan hack, but in my case it does not help >> because my program must not miss any event. >> Currently I'm using a fuse overlay filesystem to log everything. >> Not perfect but works... :-) > > Richard, > > A late follow up question. How does your application deal with the > event overflow problem (i.e., when you get a large number of events > much faster than your application can deal with them? The downside of the FUSE approach is that you have to intercept every filesystem function. This can be a performance issue. But due to this design the overflow problem cannot happen as the FUSE filesystem blocks until the event has been proceed. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] Re: recvmmsg() timeout behavior strangeness [RESEND]
Ping! On 05/22/2014 04:27 PM, Michael Kerrisk (man-pages) wrote: > Hi Arnaldo, > > On 05/21/2014 11:05 PM, Arnaldo Carvalho de Melo wrote: >> Em Mon, May 12, 2014 at 11:34:51AM -0300, Arnaldo Carvalho de Melo escreveu: >>> Em Mon, May 12, 2014 at 12:15:25PM +0200, Michael Kerrisk (man-pages) >>> escreveu: Hi Arnaldo, >> Ping! >> >>> I acknowledge the problem, the timeout has to be passed to the >>> underlying ->recvmsg() implementations that should return the time spent >>> waiting for each packet, so that we can accrue that at recvmmsg level. >> >>> We can do either passing an extra timeout parameter to the recvmsg >>> implementations or using some struct sock member to specify that >>> timeout. >> >>> The first approach is intrusive, touches tons of files, so I'll try >>> making it all mostly transparent by hooking into sock_rcvtimeo() >>> somehow. >> >> But after thinking a bit more, looks like we need to do that, please >> take a look at the attached patch to see if it addresses the problem. >> >> Mostly it adds a new timeop to the per protocol recvmsg() >> implementations, that, if not NULL, should be used instead of >> SO_RCVTIMEO. >> >> since the underlying recvmsg implementations already check that timeout, >> return what is remaining, that will then be used in subsequent recvmsg >> calls, at the end we just convert it back to timespec format. >> >> In most cases it is just passed to skb_recv_datagram, that will check >> the pointer, use it and update if not NULL. >> >> Should have no problems, but I only did a boot with a system with this >> patch applied, no problems noticed on a normal desktop session, ssh, >> etc. > > Thanks! I applied this patch against 3.15-rc6. > > recvmmsg() now (mostly) does what I expect: > * it waits until either the timeout expires or vlen messages > have been received > * If no message is received before timeout, it returns -1/EAGAIN. > * If vlen messages are received before the timeout expires, then > the remaining time is returned in timeout. > > One question: in the event that the call is interrupted by a signal > handler, it fails (as expected) with EINTR, but the 'timeout' value is > not updated with the remaining time on the timer. Would it be desirable > to emulate the behavior of select() (and other syscalls) in this > respect, and instead return the remaining time if interrupted by > a signal? > > Cheers, > > Michael > -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: inotify, new idea?
On 04/21/2014 10:42 AM, Richard Weinberger wrote: > Am 21.04.2014 09:24, schrieb Michael Kerrisk: >>> Does recursive monitoring even work with inotify? >>> Last time I've tried it did failed as soon I did a mkdir -p a/b/c/d because >>> mkdir() raced against the thread which installes the new watches. >> >> As I understand it, you have to program to deal with the races (rescan >> directories after adding watches). I recently did a lot of work >> updating the inotify(7) man page to discuss all the issues that I know >> of, and their remedies. If I missed anything, I'd appreciate a note on >> it, so that it can be added. See >> http://man7.org/linux/man-pages/man7/inotify.7.html#NOTES > > I'm aware of the rescan hack, but in my case it does not help > because my program must not miss any event. > Currently I'm using a fuse overlay filesystem to log everything. > Not perfect but works... :-) Richard, A late follow up question. How does your application deal with the event overflow problem (i.e., when you get a large number of events much faster than your application can deal with them? Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH/RFC] Re: recvmmsg() timeout behavior strangeness [RESEND]
On 05/23/2014 09:55 PM, Arnaldo Carvalho de Melo wrote: > Em Fri, May 23, 2014 at 03:00:55PM -0400, David Miller escreveu: >> From: Arnaldo Carvalho de Melo >> Date: Wed, 21 May 2014 18:05:35 -0300 > >>> But after thinking a bit more, looks like we need to do that, please >>> take a look at the attached patch to see if it addresses the problem. > >>> Mostly it adds a new timeop to the per protocol recvmsg() >>> implementations, that, if not NULL, should be used instead of >>> SO_RCVTIMEO. > >>> since the underlying recvmsg implementations already check that timeout, >>> return what is remaining, that will then be used in subsequent recvmsg >>> calls, at the end we just convert it back to timespec format. > >>> In most cases it is just passed to skb_recv_datagram, that will check >>> the pointer, use it and update if not NULL. > >>> Should have no problems, but I only did a boot with a system with this >>> patch applied, no problems noticed on a normal desktop session, ssh, >>> etc. > >> This looks fine to me, but I have a small request: > >> +return noblock ? 0 : timeop ? *timeop : sk->sk_rcvtimeo; > >> I keep forgetting which way these expressions associate, so if you could >> parenthesize the innermost ?: I'd appreciate it. :) > > Ok, I actually wrote a sample program to verify that these ternaries did > what I meant 8) > > I'll finish the cset log and do this clarification change. > > Would be great to get Acked-by tags from the original reporter, Michael > and whoever had a look at this change, if possible. Michael, Elie? Arnaldo, I already sent you a reply (will reping on that one), but got no response. My light testing got the expected results, but I still had one question about the semantics. Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [v4, resend] fcntl-linux.h: add new definitions and manual updates for open file description locks
On 05/23/2014 05:57 PM, Ondřej Bílka wrote: > On Sat, May 03, 2014 at 09:33:24AM -0400, Jeff Layton wrote: >> Open file description locks have been merged into the Linux kernel for >> v3.15. Add the appropriate command-value definitions and an update to >> the manual that describes their usage. >> >> ChangeLog: >> >> 2014-04-24 Jeff Layton >> >> [BZ#16839] >> * manual/llio.texi: add section about open file description locks >> >> * sysdeps/unix/sysv/linux/bits/fcntl-linux.h: >>(F_OFD_GETLK, F_OFD_SETLK, F_OFD_SETLKW): New macros. >> > manual/examples/ofdlocks.c entry is missing. > > Otherwise ok for me, Carlos, Michael do you have additional comments? > . After commenting quite extensively on two or three previous rounds of the patches, I have no further comments. (Jeff integrated/responded to all my comments). Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for May 21
Hi Stephen. On 05/23/2014 12:06 AM, Stephen Rothwell wrote: > Hi Michael, > > On Thu, 22 May 2014 12:45:05 +0200 Michael Kerrisk > wrote: >> >> On Wed, May 21, 2014 at 9:50 AM, Stephen Rothwell >> wrote: >>> You should use "git fetch" as mentioned in the FAQ on the wiki >>> (see below). >> >> There does not seem to be anything in the rest of your message about >> this. Did I miss something? > > The wiki went away some time ago and so I removed the other reference > to it, but missed this one. I will try to revise this message today. > Thanks for noticing - I sometimes wonder if anyone reads my release > notes :-) So, where does one find instructions on working with linux-next now? It would be good to have the basics as part of that mail, or a pointer to some location where the basics are described. Currently, one has to hunt a little bit to find something like http://lists.kernelnewbies.org/pipermail/kernelnewbies/2012-April/005178.html It would be good if that info was either part of the template mail or at a stable URL whose content is kept up to date. (I'm willing to write and host such a page, if for some reason you don't want to, but I'd like someone to confirm it's accurate.) Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
man-pages-3.67 is released
Gidday, The Linux man-pages maintainer proudly announces: man-pages-3.67 - man pages for Linux Tarball download: http://www.kernel.org/doc/man-pages/download.html Git repository: https://git.kernel.org/cgit/docs/man-pages/man-pages.git/ Online changelog: http://man7.org/linux/man-pages/changelog.html#release_3.67 A short summary of the release is blogged at: http://linux-man-pages.blogspot.com/2014/05/man-pages-367-is-released.html The current version of the pages is browsable at: http://man7.org/linux/man-pages/ A few changes in this release that may be of interest to readers of this list are given below. Cheers, Michael Changes in man-pages-3.67 New and rewritten pages --- sched_setattr.2 Michael Kerrisk, Peter Zijlstra [Juri Lelli] New page describing sched_setattr(2) and sched_getattr(2) system.3 Michael Kerrisk Rewrote large parts of the page and added a number of details Newly documented interfaces in existing pages - sched.7 Peter Zijlstra, Michael Kerrisk [Juri Lelli] Document SCHED_DEADLINE Changes to individual pages --- bind.2 Michael Kerrisk ERRORS: Add EADDRINUSE for ephemeral port range exhaustion connect.2 Michael Kerrisk [William Morriss] ERRORS: Add EADDRNOTAVAIL for ephemeral port range exhaustion Verified from testing and the kernel source. See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=745775 Michael Kerrisk Remove mention of ip_local_port_range under EAGAIN error execve.2 Michael Kerrisk [Steven Stewart-Gallus] Note SIGKILL case when execve() fails beyond the point of no return fanotify_init.2 Heinrich Schuchardt [Michael Kerrisk] Document range of permitted flags for event_f_flags With a new patch included in the mm tree, event_f_flags is checked for allowable values. recvmmsg.2 Michael Kerrisk Describe timeout bug See https://bugzilla.kernel.org/show_bug.cgi?id=75371 and http://thread.gmane.org/gmane.linux.man/5677 remap_file_pages.2 Andy Lutomirski [Christoph Hellwig, Andy Lutomirski] remap_file_pages() has no benefit for real files Linux commit 3ee6dafc677a68e461a7ddafc94a580ebab80735 caused remap_file_pages to be emulated when used on real file. proc.5 Michael Kerrisk Document /proc/timer_stats fanotify.7 Heinrich Schuchardt [Jan Kara] BUGS: error events can be lost when reading from fanotify FD ip.7 Michael Kerrisk Note cases where an ephemeral port is used Michael Kerrisk Remove BUGS text on glibc failing to declare in_pktinfo Michael Kerrisk Clarify 'ip_local_port_range' and mention the term "ephemeral ports" Michael Kerrisk Note some more details about assignment of ephemeral ports Michael Kerrisk BUGS: ephemeral port range exhaustion is diagnosed inconsistently Different system calls use different 'errno' values to diagnose exhaustion of the ephemeral port range. sched.7 Michael Kerrisk Document sched_rt_period_us and sched_rt_runtime_us /proc files And rework and relocate the text on dealing with runaway real-time processes. -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/4] devicetree: bindings: Properly document micrel ks8851 SPI chips
On Fri, May 23, 2014 at 12:57:17PM -0700, Stephen Boyd wrote: > Optional properties: > -- vdd-supply:supply for Ethernet mac > +- vdd-supply: analog 3.3V supply for Ethernet mac > +- vdd-io-supply: digital 1.8V IO supply for Ethernet mac > +- reset-gpios: reset_n input pin Are we *positive* that power is optional? I do note that there aren't any mandatory supplies for the device which seems very strange... signature.asc Description: Digital signature
[PATCH] input: tc3589x-keypad: Allocate resources using managed interfaces
This patch moves most data allocated in the probe function from
unmanaged interfaces to managed interfaces. The kfrees and error
handling code is done away with. Also, the unnecesary labels are
removed. The include for linux/device.h is added to make sure the
devm_*() routine declarations are unambiguously available.
The following Coccinelle semantic patch was used for making a part of
the change:
@platform@
identifier p, probefn, removefn;
@@
struct platform_driver p = {
.probe = probefn,
.remove = removefn,
};
@prb@
identifier platform.probefn, pdev;
expression e, e1, e2;
@@
probefn(struct platform_device *pdev, ...) {
<+...
- e = kzalloc(e1, e2)
+ e = devm_kzalloc(>dev, e1, e2)
...
?-kfree(e);
...+>
}
@rem depends on prb@
identifier platform.removefn;
expression e;
@@
removefn(...) {
<...
- kfree(e);
...>
}
Signed-off-by: Himangi Saraogi
---
drivers/input/keyboard/tc3589x-keypad.c | 35 +++--
1 file changed, 11 insertions(+), 24 deletions(-)
diff --git a/drivers/input/keyboard/tc3589x-keypad.c
b/drivers/input/keyboard/tc3589x-keypad.c
index ad7abae..c412abe 100644
--- a/drivers/input/keyboard/tc3589x-keypad.c
+++ b/drivers/input/keyboard/tc3589x-keypad.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
/* Maximum supported keypad matrix row/columns size */
#define TC3589x_MAX_KPROW 8
@@ -376,12 +377,12 @@ static int tc3589x_keypad_probe(struct platform_device
*pdev)
if (irq < 0)
return irq;
- keypad = kzalloc(sizeof(struct tc_keypad), GFP_KERNEL);
- input = input_allocate_device();
+ keypad = devm_kzalloc(>dev, sizeof(struct tc_keypad),
+ GFP_KERNEL);
+ input = devm_input_allocate_device(>dev);
if (!keypad || !input) {
dev_err(>dev, "failed to allocate keypad memory\n");
- error = -ENOMEM;
- goto err_free_mem;
+ return -ENOMEM;
}
keypad->board = plat;
@@ -400,7 +401,7 @@ static int tc3589x_keypad_probe(struct platform_device
*pdev)
NULL, input);
if (error) {
dev_err(>dev, "Failed to build keymap\n");
- goto err_free_mem;
+ return error;
}
keypad->keymap = input->keycode;
@@ -411,20 +412,20 @@ static int tc3589x_keypad_probe(struct platform_device
*pdev)
input_set_drvdata(input, keypad);
- error = request_threaded_irq(irq, NULL,
- tc3589x_keypad_irq, plat->irqtype,
- "tc3589x-keypad", keypad);
+ error = devm_request_threaded_irq(>dev, irq, NULL,
+ tc3589x_keypad_irq, plat->irqtype,
+ "tc3589x-keypad", keypad);
if (error < 0) {
dev_err(>dev,
"Could not allocate irq %d,error %d\n",
irq, error);
- goto err_free_mem;
+ return error;
}
error = input_register_device(input);
if (error) {
dev_err(>dev, "Could not register input device\n");
- goto err_free_irq;
+ return error;
}
/* let platform decide if keypad is a wakeup source or not */
@@ -434,29 +435,15 @@ static int tc3589x_keypad_probe(struct platform_device
*pdev)
platform_set_drvdata(pdev, keypad);
return 0;
-
-err_free_irq:
- free_irq(irq, keypad);
-err_free_mem:
- input_free_device(input);
- kfree(keypad);
- return error;
}
static int tc3589x_keypad_remove(struct platform_device *pdev)
{
struct tc_keypad *keypad = platform_get_drvdata(pdev);
- int irq = platform_get_irq(pdev, 0);
if (!keypad->keypad_stopped)
tc3589x_keypad_disable(keypad);
- free_irq(irq, keypad);
-
- input_unregister_device(keypad->input);
-
- kfree(keypad);
-
return 0;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] input: jornada680_kbd: Allocate resources using managed interfaces
This patch moves most data allocated in the probe function from
unmanaged interfaces to managed interfaces. The kfrees and error
handling code is done away with. Also, the unnecesary labels are
removed and the function mrstouch_remove is removed as it becomes
empty after removing the no longer required function calls. Also,
linux/device.h is added to make sure the devm_*() routine declarations
are unambiguously available.
The following Coccinelle semantic patch was used for making a part of
the change:
@platform@
identifier p, probefn, removefn;
@@
struct platform_driver p = {
.probe = probefn,
.remove = removefn,
};
@prb@
identifier platform.probefn, pdev;
expression e, e1, e2;
@@
probefn(struct platform_device *pdev, ...) {
<+...
- e = kzalloc(e1, e2)
+ e = devm_kzalloc(>dev, e1, e2)
...
?-kfree(e);
...+>
}
@rem depends on prb@
identifier platform.removefn;
expression e;
@@
removefn(...) {
<...
- kfree(e);
...>
}
Signed-off-by: Himangi Saraogi
---
Not compile tested due to incompatible architecture.
drivers/input/keyboard/jornada680_kbd.c | 21 -
1 file changed, 4 insertions(+), 17 deletions(-)
diff --git a/drivers/input/keyboard/jornada680_kbd.c
b/drivers/input/keyboard/jornada680_kbd.c
index 69b1f00..806dc6b 100644
--- a/drivers/input/keyboard/jornada680_kbd.c
+++ b/drivers/input/keyboard/jornada680_kbd.c
@@ -16,6 +16,7 @@
* published by the Free Software Foundation.
*/
+#include
#include
#include
#include
@@ -185,11 +186,12 @@ static int jornada680kbd_probe(struct platform_device
*pdev)
struct input_dev *input_dev;
int i, error;
- jornadakbd = kzalloc(sizeof(struct jornadakbd), GFP_KERNEL);
+ jornadakbd = devm_kzalloc(>dev, sizeof(struct jornadakbd),
+ GFP_KERNEL);
if (!jornadakbd)
return -ENOMEM;
- poll_dev = input_allocate_polled_device();
+ poll_dev = devm_input_allocate_polled_device(>dev);
if (!poll_dev) {
error = -ENOMEM;
goto failed;
@@ -232,21 +234,7 @@ static int jornada680kbd_probe(struct platform_device
*pdev)
failed:
printk(KERN_ERR "Jornadakbd: failed to register driver, error: %d\n",
error);
- input_free_polled_device(poll_dev);
- kfree(jornadakbd);
return error;
-
-}
-
-static int jornada680kbd_remove(struct platform_device *pdev)
-{
- struct jornadakbd *jornadakbd = platform_get_drvdata(pdev);
-
- input_unregister_polled_device(jornadakbd->poll_dev);
- input_free_polled_device(jornadakbd->poll_dev);
- kfree(jornadakbd);
-
- return 0;
}
static struct platform_driver jornada680kbd_driver = {
@@ -255,7 +243,6 @@ static struct platform_driver jornada680kbd_driver = {
.owner = THIS_MODULE,
},
.probe = jornada680kbd_probe,
- .remove = jornada680kbd_remove,
};
module_platform_driver(jornada680kbd_driver);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] acornscsi: remove linked command support
On Sat, 2014-05-24 at 12:35 +0200, Hannes Reinecke wrote: [...] > I'm all for it. Removing never-really-implemented feature on obsolete > hardware is always a good idea. > > Acked-by: Hannes Reinecke Wait, no, that's not a good idea. We leave obsolete drivers to bitrot. Particularly we try not to touch them unless we have to because there might be a few people still using them and the more we tamper, the greater the risk that something gets broken. On that principle, since there's no real reason to remove the code, it should stay ... until the whole driver bitrots to the extent that we can no-longer compile it. However, I'll do this if the Maintainer (rmk) acks ... because if it breaks he gets to fix it. James -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] lib/textsearch.c: move EXPORT_SYMBOL after functions
Fix checkpatch warning:
"WARNING: EXPORT_SYMBOL(foo); should immediately follow its function/variable"
Cc: Andrew Morton
Signed-off-by: Fabian Frederick
---
lib/textsearch.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/lib/textsearch.c b/lib/textsearch.c
index e0cc014..0c7e9ab 100644
--- a/lib/textsearch.c
+++ b/lib/textsearch.c
@@ -159,6 +159,7 @@ errout:
spin_unlock(_mod_lock);
return err;
}
+EXPORT_SYMBOL(textsearch_register);
/**
* textsearch_unregister - unregister a textsearch module
@@ -190,6 +191,7 @@ out:
spin_unlock(_mod_lock);
return err;
}
+EXPORT_SYMBOL(textsearch_unregister);
struct ts_linear_state
{
@@ -236,6 +238,7 @@ unsigned int textsearch_find_continuous(struct ts_config
*conf,
return textsearch_find(conf, state);
}
+EXPORT_SYMBOL(textsearch_find_continuous);
/**
* textsearch_prepare - Prepare a search
@@ -298,6 +301,7 @@ errout:
return ERR_PTR(err);
}
+EXPORT_SYMBOL(textsearch_prepare);
/**
* textsearch_destroy - destroy a search configuration
@@ -316,9 +320,4 @@ void textsearch_destroy(struct ts_config *conf)
kfree(conf);
}
-
-EXPORT_SYMBOL(textsearch_register);
-EXPORT_SYMBOL(textsearch_unregister);
-EXPORT_SYMBOL(textsearch_prepare);
-EXPORT_SYMBOL(textsearch_find_continuous);
EXPORT_SYMBOL(textsearch_destroy);
--
1.8.4.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i2c-davinci: Handle signals gracefully
On 05/21/2014 10:17 AM, Wolfram Sang wrote:
dev_err(dev->dev, "controller timed out\n");
davinci_i2c_recover_bus(dev);
i2c_davinci_init(dev);
@@ -384,7 +384,6 @@ i2c_davinci_xfer_msg(struct i2c_adapter *adap, struct
i2c_msg *msg, int stop)
if (dev->buf_len) {
/* This should be 0 if all bytes were transferred
* or dev->cmd_err denotes an error.
-* A signal may have aborted the transfer.
*/
if (r >= 0) {
dev_err(dev->dev, "abnormal termination buf_len=%i\n",
@@ -436,22 +435,24 @@ i2c_davinci_xfer(struct i2c_adapter *adap, struct i2c_msg
msgs[], int num)
ret = i2c_davinci_wait_bus_not_busy(dev, 1);
if (ret < 0) {
dev_warn(dev->dev, "timeout waiting for bus ready\n");
- return ret;
+ goto error;
You are fixing the error path here to include the completion? This is a
seperate patch IMO.
Is my remark true? I still prefer the seperate patch, but we may also
simply update the commit message.
Your remarks is correct. All your remarks were. Problem currently is
that I'm not assigned to a project related to the davinci so I cannot
spend time to fix and port it (the actual platform still runs 2.6.37).
Feel free to adap my patch or comments and commit. Or wait a few weeks
for when I have a sponsor to split and update the patch.
--
Mike Looijmans
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
