Re: [PATCH] net/core/sock.c: add missing VSOCK string in af_family_*_key_strings
From: Sergei Shtylyov Date: Tue, 28 May 2013 21:58:52 +0400 > Hello. > > On 28-05-2013 19:02, Federico Vaga wrote: > >> The three arrays of strings: af_family_kay_strings, > >s/kay/key/. Maybe whoever applies this could fix the typo... Applied with typo fixed and queued up for -stable. 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/FIX] net: Block MSG_CMSG_COMPAT in send(m)msg and recv(m)msg
From: Ingo Molnar Date: Tue, 28 May 2013 10:56:00 +0200 > MSG_CMSG_COMPAT is (AFAIK) not intended to be part of the API -- > it's a hack that steals a bit to indicate to other networking code > that a compat entry was used. So don't allow it from a non-compat > syscall. > > This prevents an oops when running this code: ... > Cc: David S. Miller > Signed-off-by: Andy Lutomirski Applied and queued up for -stable. -- 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] usb: dwc3: omap Modify dwc3_omap_readl/writel with offsets
> -Original Message-
> From: Balbi, Felipe
> Sent: Tuesday, May 28, 2013 11:02 PM
> To: Cherian, George
> Cc: Balbi, Felipe; linux-...@vger.kernel.org; linux-o...@vger.kernel.org;
> linux-kernel@vger.kernel.org; gre...@linuxfoundation.org
> Subject: Re: [PATCH 3/3] usb: dwc3: omap Modify dwc3_omap_readl/writel
> with offsets
>
> Hi,
>
> On Mon, May 27, 2013 at 01:32:57PM +0530, George Cherian wrote:
> > This patch modifies dwc3_omap_readl/writel calls to accomodate
> > both OMAP5 and AM437x reg maps (It uses the cached register offsets).
> > Also renames OMAP5 IRQ1 as IRQMISC, IRQ1 bits as IRQMISC bits.
> >
> > Signed-off-by: George Cherian
>
> can you change this patch a bit so that it adds wrappers around
> dwc3_omap_*() ? The idea is the have the code look like:
>
> static u32 dwc3_omap_read_utmi_status(struct dwc3_omap *omap)
> {
> return dwc3_omap_readl(omap->base,
> USBOTGSS_UTMI_OTG_STATUS +
> omap->utmi_otg_offset);
> }
>
> (likewise for write and for all other offsets, of course)
>
> that way, reading/writing to registers which need the offset will be
> less error-prone and th driver will look a little nicer.
Yes , I will do it in next version.
>
> --
> Balbi
-George
--
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 0/2] clk: add of_clk_provider stubs to enable clk-si5351 on non OF
Quoting Sebastian Hesselbarth (2013-04-30 17:58:27) > Enabling drivers that provide clocks on DT on platforms that don't have > CONFIG_OF set fails due to compilation errors. This patch set first adds > some stubs for of_clk_provider functions if CONFIG_OF is not set. Second > it allows those platforms to build and use clk-si5351 i2c clock driver > by removing the dependency on CONFIG_OF. > > The above approach has been suggested by Arnd Bergmann and replaces the > corresponding Kconfig patch for clk-si5351 posted earlier. It has been > compile tested with allmodconfig on x86_64 for post v3.9. > > Sebastian Hesselbarth (2): > clk: add non CONFIG_OF routines for clk-provider > clk: si5351: Allow to build without CONFIG_OF > Both are taken into clk-next. Thanks, Mike > drivers/clk/Kconfig |1 - > include/linux/clk-provider.h | 47 > +++--- > 2 files changed, 39 insertions(+), 9 deletions(-) > --- > Cc: Mike Turquette > Cc: Linus Walleij > Cc: Andrew Morton > Cc: Peter Ujfalusi > Cc: Arnd Bergmann > Cc: Stephen Warren > Cc: Daniel Mack > Cc: Lars-Peter Clausen > Cc: Guenter Roeck > Cc: Marek Belisko > Cc: linux-arm-ker...@lists.infradead.org > Cc: linux-kernel@vger.kernel.org > -- > 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/
[PATCH v6 net-next 5/5] ixgbe: add extra stats for ndo_ll_poll
Add additional statistics to the ixgbe driver for ndo_ll_poll
Defined under LL_EXTENDED_STATS
Signed-off-by: Alexander Duyck
Signed-off-by: Jesse Brandeburg
Tested-by: Willem de Bruijn
Signed-off-by: Eliezer Tamir
---
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 14
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 40 ++
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c|6 +++
3 files changed, 60 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
index 04fdbf6..9765772 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
@@ -54,6 +54,9 @@
#include
+#ifdef CONFIG_NET_LL_RX_POLL
+#define LL_EXTENDED_STATS
+#endif
/* common prefix used by pr_<> macros */
#undef pr_fmt
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
@@ -184,6 +187,11 @@ struct ixgbe_rx_buffer {
struct ixgbe_queue_stats {
u64 packets;
u64 bytes;
+#ifdef LL_EXTENDED_STATS
+ u64 yields;
+ u64 misses;
+ u64 cleaned;
+#endif /* LL_EXTENDED_STATS */
};
struct ixgbe_tx_queue_stats {
@@ -391,6 +399,9 @@ static inline int ixgbe_qv_lock_napi(struct ixgbe_q_vector
*q_vector)
WARN_ON(q_vector->state & IXGBE_QV_STATE_NAPI);
q_vector->state |= IXGBE_QV_STATE_NAPI_YIELD;
rc = false;
+#ifdef LL_EXTENDED_STATS
+ q_vector->tx.ring->stats.yields++;
+#endif
} else
/* we don't care if someone yielded */
q_vector->state = IXGBE_QV_STATE_NAPI;
@@ -421,6 +432,9 @@ static inline int ixgbe_qv_lock_poll(struct ixgbe_q_vector
*q_vector)
if ((q_vector->state & IXGBE_QV_LOCKED)) {
q_vector->state |= IXGBE_QV_STATE_POLL_YIELD;
rc = false;
+#ifdef LL_EXTENDED_STATS
+ q_vector->rx.ring->stats.yields++;
+#endif
} else
/* preserve yield marks */
q_vector->state |= IXGBE_QV_STATE_POLL;
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
index d375472..24e2e7a 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
@@ -1054,6 +1054,12 @@ static void ixgbe_get_ethtool_stats(struct net_device
*netdev,
data[i] = 0;
data[i+1] = 0;
i += 2;
+#ifdef LL_EXTENDED_STATS
+ data[i] = 0;
+ data[i+1] = 0;
+ data[i+2] = 0;
+ i += 3;
+#endif
continue;
}
@@ -1063,6 +1069,12 @@ static void ixgbe_get_ethtool_stats(struct net_device
*netdev,
data[i+1] = ring->stats.bytes;
} while (u64_stats_fetch_retry_bh(&ring->syncp, start));
i += 2;
+#ifdef LL_EXTENDED_STATS
+ data[i] = ring->stats.yields;
+ data[i+1] = ring->stats.misses;
+ data[i+2] = ring->stats.cleaned;
+ i += 3;
+#endif
}
for (j = 0; j < IXGBE_NUM_RX_QUEUES; j++) {
ring = adapter->rx_ring[j];
@@ -1070,6 +1082,12 @@ static void ixgbe_get_ethtool_stats(struct net_device
*netdev,
data[i] = 0;
data[i+1] = 0;
i += 2;
+#ifdef LL_EXTENDED_STATS
+ data[i] = 0;
+ data[i+1] = 0;
+ data[i+2] = 0;
+ i += 3;
+#endif
continue;
}
@@ -1079,6 +1097,12 @@ static void ixgbe_get_ethtool_stats(struct net_device
*netdev,
data[i+1] = ring->stats.bytes;
} while (u64_stats_fetch_retry_bh(&ring->syncp, start));
i += 2;
+#ifdef LL_EXTENDED_STATS
+ data[i] = ring->stats.yields;
+ data[i+1] = ring->stats.misses;
+ data[i+2] = ring->stats.cleaned;
+ i += 3;
+#endif
}
for (j = 0; j < IXGBE_MAX_PACKET_BUFFERS; j++) {
@@ -1115,12 +1139,28 @@ static void ixgbe_get_strings(struct net_device
*netdev, u32 stringset,
p += ETH_GSTRING_LEN;
sprintf(p, "tx_queue_%u_bytes", i);
p += ETH_GSTRING_LEN;
+#ifdef LL_EXTENDED_STATS
+ sprintf(p, "tx_q_%u_napi_yield", i);
+ p += ETH_GSTRING_LEN;
+ sprintf(p, "tx_q_%u_misses", i);
+ p += ETH_GSTRING_LEN;
+ sprintf(p, "tx_q_%u_cleaned", i);
+ p += ETH_GSTRING_LEN;
+#endif /* LL_EXTENDED_STATS */
}
for (i = 0; i < IXGBE_NUM_RX_QUEUES; i++) {
sprintf(p, "rx_queue_%u_packets", i);
[PATCH v6 net-next 3/5] tcp: add TCP support for low latency receive poll.
Adds busy-poll support for TCP. Copy the napi_id from an incomming skb to the sk in tcp_v[46]_rcv(). when there is no data in the socket we busy-poll in tcp_recvmsg(). This is a good example of how to add busy-poll support to new protocols. Signed-off-by: Alexander Duyck Signed-off-by: Jesse Brandeburg Tested-by: Willem de Bruijn Signed-off-by: Eliezer Tamir --- net/ipv4/tcp.c |5 + net/ipv4/tcp_ipv4.c |2 ++ net/ipv6/tcp_ipv6.c |2 ++ 3 files changed, 9 insertions(+), 0 deletions(-) diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c index ba4186e..becd105 100644 --- a/net/ipv4/tcp.c +++ b/net/ipv4/tcp.c @@ -279,6 +279,7 @@ #include #include +#include int sysctl_tcp_fin_timeout __read_mostly = TCP_FIN_TIMEOUT; @@ -1551,6 +1552,10 @@ int tcp_recvmsg(struct kiocb *iocb, struct sock *sk, struct msghdr *msg, struct sk_buff *skb; u32 urg_hole = 0; + if (sk_valid_ll(sk) && skb_queue_empty(&sk->sk_receive_queue) + && (sk->sk_state == TCP_ESTABLISHED)) + sk_poll_ll(sk, nonblock); + lock_sock(sk); err = -ENOTCONN; diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c index d20ede0..35fd8bc 100644 --- a/net/ipv4/tcp_ipv4.c +++ b/net/ipv4/tcp_ipv4.c @@ -75,6 +75,7 @@ #include #include #include +#include #include #include @@ -2011,6 +2012,7 @@ process: if (sk_filter(sk, skb)) goto discard_and_relse; + sk_mark_ll(sk, skb); skb->dev = NULL; bh_lock_sock_nested(sk); diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c index 0a17ed9..5cffa5c 100644 --- a/net/ipv6/tcp_ipv6.c +++ b/net/ipv6/tcp_ipv6.c @@ -63,6 +63,7 @@ #include #include #include +#include #include @@ -1498,6 +1499,7 @@ process: if (sk_filter(sk, skb)) goto discard_and_relse; + sk_mark_ll(sk, skb); skb->dev = NULL; bh_lock_sock_nested(sk); -- 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 v6 net-next 4/5] ixgbe: Add support for ndo_ll_poll
Add the ixgbe driver code implementing ndo_ll_poll.
It should be easy for other drivers to do something similar
in order to enable support for CONFIG_NET_LL_RX_POLL
Signed-off-by: Alexander Duyck
Signed-off-by: Jesse Brandeburg
Tested-by: Willem de Bruijn
Signed-off-by: Eliezer Tamir
---
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 120 +
drivers/net/ethernet/intel/ixgbe/ixgbe_lib.c |2
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 63 +++--
3 files changed, 177 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
index ca93238..04fdbf6 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
@@ -52,6 +52,8 @@
#include
#endif
+#include
+
/* common prefix used by pr_<> macros */
#undef pr_fmt
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
@@ -356,9 +358,127 @@ struct ixgbe_q_vector {
struct rcu_head rcu;/* to avoid race with update stats on free */
char name[IFNAMSIZ + 9];
+#ifdef CONFIG_NET_LL_RX_POLL
+ unsigned int state;
+#define IXGBE_QV_STATE_IDLE0
+#define IXGBE_QV_STATE_NAPI 1/* NAPI owns this QV */
+#define IXGBE_QV_STATE_POLL 2/* poll owns this QV */
+#define IXGBE_QV_LOCKED (IXGBE_QV_STATE_NAPI | IXGBE_QV_STATE_POLL)
+#define IXGBE_QV_STATE_NAPI_YIELD 4/* NAPI yielded this QV */
+#define IXGBE_QV_STATE_POLL_YIELD 8/* poll yielded this QV */
+#define IXGBE_QV_YIELD (IXGBE_QV_STATE_NAPI_YIELD | IXGBE_QV_STATE_POLL_YIELD)
+#define IXGBE_QV_USER_PEND (IXGBE_QV_STATE_POLL | IXGBE_QV_STATE_POLL_YIELD)
+ spinlock_t lock;
+#endif /* CONFIG_NET_LL_RX_POLL */
+
/* for dynamic allocation of rings associated with this q_vector */
struct ixgbe_ring ring[0] cacheline_internodealigned_in_smp;
};
+#ifdef CONFIG_NET_LL_RX_POLL
+static inline void ixgbe_qv_init_lock(struct ixgbe_q_vector *q_vector)
+{
+
+ spin_lock_init(&q_vector->lock);
+ q_vector->state = IXGBE_QV_STATE_IDLE;
+}
+
+/* called from the device poll rutine to get ownership of a q_vector */
+static inline int ixgbe_qv_lock_napi(struct ixgbe_q_vector *q_vector)
+{
+ int rc = true;
+ spin_lock(&q_vector->lock);
+ if (q_vector->state & IXGBE_QV_LOCKED) {
+ WARN_ON(q_vector->state & IXGBE_QV_STATE_NAPI);
+ q_vector->state |= IXGBE_QV_STATE_NAPI_YIELD;
+ rc = false;
+ } else
+ /* we don't care if someone yielded */
+ q_vector->state = IXGBE_QV_STATE_NAPI;
+ spin_unlock(&q_vector->lock);
+ return rc;
+}
+
+/* returns true is someone tried to get the qv while napi had it */
+static inline int ixgbe_qv_unlock_napi(struct ixgbe_q_vector *q_vector)
+{
+ int rc = false;
+ spin_lock(&q_vector->lock);
+ WARN_ON(q_vector->state & (IXGBE_QV_STATE_POLL |
+ IXGBE_QV_STATE_NAPI_YIELD));
+
+ if (q_vector->state & IXGBE_QV_STATE_POLL_YIELD)
+ rc = true;
+ q_vector->state = IXGBE_QV_STATE_IDLE;
+ spin_unlock(&q_vector->lock);
+ return rc;
+}
+
+/* called from ixgbe_low_latency_poll() */
+static inline int ixgbe_qv_lock_poll(struct ixgbe_q_vector *q_vector)
+{
+ int rc = true;
+ spin_lock_bh(&q_vector->lock);
+ if ((q_vector->state & IXGBE_QV_LOCKED)) {
+ q_vector->state |= IXGBE_QV_STATE_POLL_YIELD;
+ rc = false;
+ } else
+ /* preserve yield marks */
+ q_vector->state |= IXGBE_QV_STATE_POLL;
+ spin_unlock_bh(&q_vector->lock);
+ return rc;
+}
+
+/* returns true if someone tried to get the qv while it was locked */
+static inline int ixgbe_qv_unlock_poll(struct ixgbe_q_vector *q_vector)
+{
+ int rc = false;
+ spin_lock_bh(&q_vector->lock);
+ WARN_ON(q_vector->state & (IXGBE_QV_STATE_NAPI));
+
+ if (q_vector->state & IXGBE_QV_STATE_POLL_YIELD)
+ rc = true;
+ q_vector->state = IXGBE_QV_STATE_IDLE;
+ spin_unlock_bh(&q_vector->lock);
+ return rc;
+}
+
+/* true if a socket is polling, even if it did not get the lock */
+static inline int ixgbe_qv_ll_polling(struct ixgbe_q_vector *q_vector)
+{
+ WARN_ON(!(q_vector->state & IXGBE_QV_LOCKED));
+ return q_vector->state & IXGBE_QV_USER_PEND;
+}
+#else /* CONFIG_NET_LL_RX_POLL */
+static inline void ixgbe_qv_init_lock(struct ixgbe_q_vector *q_vector)
+{
+}
+
+static inline int ixgbe_qv_lock_napi(struct ixgbe_q_vector *q_vector)
+{
+ return true;
+}
+
+static inline int ixgbe_qv_unlock_napi(struct ixgbe_q_vector *q_vector)
+{
+ return false;
+}
+
+static inline int ixgbe_qv_lock_poll(struct ixgbe_q_vector *q_vector)
+{
+ return false;
+}
+
+static inline int ixgbe_qv_unlock_poll(struct ixgbe_q_vector *q_vector)
+{
+ return false;
+}
+
+static inline int ixgbe_qv_ll_polling(struct ixgbe_q_
[PATCH v6 net-next 2/5] net: implement support for low latency socket polling
Adds a new ndo_ll_poll method and the code that supports and uses it.
This method can be used by low latency applications to busy poll Ethernet
device queues directly from the socket code. The value of sysctl_net_ll_poll
controls how many microseconds to poll. Set to zero to disable.
Signed-off-by: Alexander Duyck
Signed-off-by: Jesse Brandeburg
Tested-by: Willem de Bruijn
Signed-off-by: Eliezer Tamir
---
Documentation/sysctl/net.txt |7 ++
fs/select.c |7 ++
include/linux/netdevice.h|3 +
include/linux/skbuff.h |8 ++-
include/net/ll_poll.h| 126 ++
include/net/sock.h |4 +
include/uapi/linux/snmp.h|1
net/Kconfig | 12
net/core/datagram.c |4 +
net/core/skbuff.c|4 +
net/core/sock.c |6 ++
net/core/sysctl_net_core.c | 10 +++
net/ipv4/proc.c |1
net/ipv4/udp.c |6 ++
net/ipv6/udp.c |6 ++
net/socket.c | 16 +
16 files changed, 216 insertions(+), 5 deletions(-)
create mode 100644 include/net/ll_poll.h
diff --git a/Documentation/sysctl/net.txt b/Documentation/sysctl/net.txt
index c1f8640..85ab72d 100644
--- a/Documentation/sysctl/net.txt
+++ b/Documentation/sysctl/net.txt
@@ -50,6 +50,13 @@ The maximum number of packets that kernel can handle on a
NAPI interrupt,
it's a Per-CPU variable.
Default: 64
+low_latency_poll
+
+Low latency busy poll timeout. (needs CONFIG_NET_LL_RX_POLL)
+Approximate time in us to spin waiting for packets on the device queue.
+Recommended value is 50. May increase power usage.
+Default: 0 (off)
+
rmem_default
diff --git a/fs/select.c b/fs/select.c
index 8c1c96c..0ef246d 100644
--- a/fs/select.c
+++ b/fs/select.c
@@ -27,6 +27,7 @@
#include
#include
#include
+#include
#include
@@ -400,6 +401,7 @@ int do_select(int n, fd_set_bits *fds, struct timespec
*end_time)
poll_table *wait;
int retval, i, timed_out = 0;
unsigned long slack = 0;
+ unsigned long ll_time = ll_end_time();
rcu_read_lock();
retval = max_select_fd(n, fds);
@@ -486,6 +488,8 @@ int do_select(int n, fd_set_bits *fds, struct timespec
*end_time)
break;
}
+ if (can_poll_ll(ll_time))
+ continue;
/*
* If this is the first loop and we have a timeout
* given, then we convert to ktime_t and set the to
@@ -750,6 +754,7 @@ static int do_poll(unsigned int nfds, struct poll_list
*list,
ktime_t expire, *to = NULL;
int timed_out = 0, count = 0;
unsigned long slack = 0;
+ unsigned long ll_time = ll_end_time();
/* Optimise the no-wait case */
if (end_time && !end_time->tv_sec && !end_time->tv_nsec) {
@@ -795,6 +800,8 @@ static int do_poll(unsigned int nfds, struct poll_list
*list,
if (count || timed_out)
break;
+ if (can_poll_ll(ll_time))
+ continue;
/*
* If this is the first loop and we have a timeout
* given, then we convert to ktime_t and set the to
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 964648e..7acea42 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -972,6 +972,9 @@ struct net_device_ops {
gfp_t gfp);
void(*ndo_netpoll_cleanup)(struct net_device *dev);
#endif
+#ifdef CONFIG_NET_LL_RX_POLL
+ int (*ndo_ll_poll)(struct napi_struct *dev);
+#endif
int (*ndo_set_vf_mac)(struct net_device *dev,
int queue, u8 *mac);
int (*ndo_set_vf_vlan)(struct net_device *dev,
diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
index 8f2b830..77f0a14 100644
--- a/include/linux/skbuff.h
+++ b/include/linux/skbuff.h
@@ -386,6 +386,7 @@ typedef unsigned char *sk_buff_data_t;
* @no_fcs: Request NIC to treat last 4 bytes as Ethernet FCS
* @dma_cookie: a cookie to one of several possible DMA operations
* done by skb DMA functions
+ *@napi_id: id of the NAPI struct this skb came from
* @secmark: security marking
* @mark: Generic packet mark
* @dropcount: total number of sk_receive_queue overflows
@@ -500,8 +501,11 @@ struct sk_buff {
/* 7/9 bit hole (depending on ndisc_nodetype presence) */
kmemcheck_bitfield_end(flags2);
-#ifdef CONFIG_NET_DMA
- dma_cookie_tdma_cookie;
+#if defined CONFIG_NET_DMA || defined CONFIG_NET_LL_RX_POLL
+ union {
+ unsigned intnapi_id;
+ dma_cookie_tdma_cookie;
[PATCH v6 net-next 0/5] net: low latency Ethernet device polling
One more round of fixes. Thank you all for your input. -Eliezer change log: v6 - many small fixes suggested by Eric Dumazet: data locality, typos, documentation protect napi_hash insert/delete with a spinlock (napi_gen_id is no longer atomic_t since it's only accessed with the spinlock held.) - added IPv6 TCP and UDP support (only minimally tested) v5 - corrections suggested by Ben Hutchings: fixed typos, moved the config option and sysctl value from IPv4 to net - moved sk_mark_ll() to the protocol handlers - removed global id mechanism, replaced with a hashed napi_id. based on code sample from Eric Dumazet Note that ixgbe_free_q_vector() already waits an rcu grace period before freeing the q_vector, so nothing additional needs to be done when adding a call to napi_hash_del(). - simple poll/select support v4 - removed separate config option for TCP as suggested Eric Dumazet. - added linux mib counter for packets received through the low latency path, as suggested by Andi Kleen. - re-allow module unloading, remove module param, use a global generation id instead to prevent the use of a stale napi pointer, as suggested by Eric Dumazet - updated Documentation/networking/ip-sysctl.txt text v3 - coding style changes suggested by Dave Miller v2 - the sysctl knob is now in microseconds. The default value is now 0 (off). - for now the code depends at configure time on CONFIG_I86_TSC - the napi reference in struct skb is now a union with the dma cookie since the former is only used on RX and the latter on TX, as suggested by Eric Dumazet. - we do a better job at honoring non-blocking operations. - removed busy-polling support for tcp_read_sock() - remove dynamic disabling of GRO - coding style fixes - disallow unloading the device module after the feature has been used Credit: Jesse Brandeburg, Arun Chekhov Ilango, Julie Cummings, Alexander Duyck, Eric Geisler, Jason Neighbors, Yadong Li, Mike Polehn, Anil Vasudevan, Don Wood Special thanks for finding bugs in earlier versions: Willem de Bruijn and Andi Kleen Thanks, Eliezer -- 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 v6 net-next 1/5] net: add napi_id and hash
Adds a napi_id and a hashing mechanism to lookup a napi by id.
This will be used by subsequent patches to implement low latency
Ethernet device polling.
Based on a code sample by Eric Dumazet.
Signed-off-by: Eliezer Tamir
---
include/linux/netdevice.h | 29
net/core/dev.c| 54 +
2 files changed, 83 insertions(+), 0 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 8f967e3..964648e 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -324,12 +324,15 @@ struct napi_struct {
struct sk_buff *gro_list;
struct sk_buff *skb;
struct list_headdev_list;
+ struct hlist_node napi_hash_node;
+ unsigned intnapi_id;
};
enum {
NAPI_STATE_SCHED, /* Poll is scheduled */
NAPI_STATE_DISABLE, /* Disable pending */
NAPI_STATE_NPSVC, /* Netpoll - don't dequeue from poll_list */
+ NAPI_STATE_HASHED, /* In NAPI hash */
};
enum gro_result {
@@ -446,6 +449,32 @@ extern void __napi_complete(struct napi_struct *n);
extern void napi_complete(struct napi_struct *n);
/**
+ * napi_hash_add - add a NAPI to global hashtable
+ * @napi: napi context
+ *
+ * generate a new napi_id and store a @napi under it in napi_hash
+ */
+extern void napi_hash_add(struct napi_struct *napi);
+
+/**
+ * napi_hash_del - remove a NAPI from global table
+ * @napi: napi context
+ *
+ * Warning: caller must observe rcu grace period
+ * before freeing memory containing @napi
+ */
+extern void napi_hash_del(struct napi_struct *napi);
+
+/**
+ * napi_by_id - lookup a NAPI by napi_id
+ * @napi_id: hashed napi_id
+ *
+ * lookup @napi_id in napi_hash table
+ * must be called under rcu_read_lock()
+ */
+extern struct napi_struct *napi_by_id(int napi_id);
+
+/**
* napi_disable - prevent NAPI from scheduling
* @n: napi context
*
diff --git a/net/core/dev.c b/net/core/dev.c
index b2e9057..0f39481 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -129,6 +129,7 @@
#include
#include
#include
+#include
#include "net-sysfs.h"
@@ -166,6 +167,12 @@ static struct list_head offload_base __read_mostly;
DEFINE_RWLOCK(dev_base_lock);
EXPORT_SYMBOL(dev_base_lock);
+/* protects napi_hash addition/deletion and napi_gen_id */
+DEFINE_SPINLOCK(napi_hash_lock);
+
+unsigned int napi_gen_id;
+DEFINE_HASHTABLE(napi_hash, 8);
+
seqcount_t devnet_rename_seq;
static inline void dev_base_seq_inc(struct net *net)
@@ -4136,6 +4143,53 @@ void napi_complete(struct napi_struct *n)
}
EXPORT_SYMBOL(napi_complete);
+void napi_hash_add(struct napi_struct *napi)
+{
+ if (!test_and_set_bit(NAPI_STATE_HASHED, &napi->state)) {
+
+ spin_lock(&napi_hash_lock);
+
+ /* 0 is not a valid id */
+ napi->napi_id = 0;
+ while (!napi->napi_id)
+ napi->napi_id = ++napi_gen_id;
+
+ hlist_add_head_rcu(&napi->napi_hash_node,
+ &napi_hash[napi->napi_id % HASH_SIZE(napi_hash)]);
+
+ spin_unlock(&napi_hash_lock);
+ }
+}
+EXPORT_SYMBOL_GPL(napi_hash_add);
+
+/* Warning : caller is responsible to make sure rcu grace period
+ * is respected before freeing memory containing @napi
+ */
+void napi_hash_del(struct napi_struct *napi)
+{
+ spin_lock(&napi_hash_lock);
+
+ if (test_and_clear_bit(NAPI_STATE_HASHED, &napi->state))
+ hlist_del_rcu(&napi->napi_hash_node);
+
+ spin_unlock(&napi_hash_lock);
+}
+EXPORT_SYMBOL_GPL(napi_hash_del);
+
+/* must be called under rcu_read_lock(), as we dont take a reference */
+struct napi_struct *napi_by_id(int napi_id)
+{
+ unsigned int hash = napi_id % HASH_SIZE(napi_hash);
+ struct napi_struct *napi;
+
+ hlist_for_each_entry_rcu(napi, &napi_hash[hash], napi_hash_node)
+ if (napi->napi_id == napi_id)
+ return napi;
+
+ return NULL;
+}
+EXPORT_SYMBOL_GPL(napi_by_id);
+
void netif_napi_add(struct net_device *dev, struct napi_struct *napi,
int (*poll)(struct napi_struct *, int), int weight)
{
--
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] ceph: tidy ceph_mdsmap_decode() a little
I introduced a new temporary variable "info" instead of
"m->m_info[mds]". Also I reversed the if condition and pulled
everything in one indent level.
Signed-off-by: Dan Carpenter
---
This goes on top of Emil Goode's patch.
diff --git a/fs/ceph/mdsmap.c b/fs/ceph/mdsmap.c
index d4d3897..132b64e 100644
--- a/fs/ceph/mdsmap.c
+++ b/fs/ceph/mdsmap.c
@@ -92,6 +92,7 @@ struct ceph_mdsmap *ceph_mdsmap_decode(void **p, void *end)
u32 num_export_targets;
void *pexport_targets = NULL;
struct ceph_timespec laggy_since;
+ struct ceph_mds_info *info;
ceph_decode_need(p, end, sizeof(u64)*2 + 1 + sizeof(u32), bad);
global_id = ceph_decode_64(p);
@@ -126,26 +127,27 @@ struct ceph_mdsmap *ceph_mdsmap_decode(void **p, void
*end)
i+1, n, global_id, mds, inc,
ceph_pr_addr(&addr.in_addr),
ceph_mds_state_name(state));
- if (mds >= 0 && mds < m->m_max_mds && state > 0) {
- m->m_info[mds].global_id = global_id;
- m->m_info[mds].state = state;
- m->m_info[mds].addr = addr;
- m->m_info[mds].laggy =
- (laggy_since.tv_sec != 0 ||
-laggy_since.tv_nsec != 0);
- m->m_info[mds].num_export_targets = num_export_targets;
- if (num_export_targets) {
- m->m_info[mds].export_targets =
- kcalloc(num_export_targets, sizeof(u32),
- GFP_NOFS);
- if (m->m_info[mds].export_targets == NULL)
- goto badmem;
- for (j = 0; j < num_export_targets; j++)
- m->m_info[mds].export_targets[j] =
- ceph_decode_32(&pexport_targets);
- } else {
- m->m_info[mds].export_targets = NULL;
- }
+
+ if (mds < 0 || mds >= m->m_max_mds || state <= 0)
+ continue;
+
+ info = &m->m_info[mds];
+ info->global_id = global_id;
+ info->state = state;
+ info->addr = addr;
+ info->laggy = (laggy_since.tv_sec != 0 ||
+ laggy_since.tv_nsec != 0);
+ info->num_export_targets = num_export_targets;
+ if (num_export_targets) {
+ info->export_targets = kcalloc(num_export_targets,
+ sizeof(u32), GFP_NOFS);
+ if (info->export_targets == NULL)
+ goto badmem;
+ for (j = 0; j < num_export_targets; j++)
+ info->export_targets[j] =
+ ceph_decode_32(&pexport_targets);
+ } else {
+ info->export_targets = NULL;
}
}
--
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: PING^7 (was Re: [PATCH v2 00/14] Corrections and customization of the SG_IO command whitelist (CVE-2012-4542))
Martin K. Petersen, on 05/28/2013 01:25 PM wrote: > Vladislav> Linux block layer is purely artificial creature slowly > Vladislav> reinventing wheel creating more problems, than solving. > > On the contrary. I do think we solve a whole bunch of problems. > > > Vladislav> It enforces approach, where often "impossible" means > Vladislav> "impossible in this interface". > > I agree we have limitations. I do not agree that all limitations are > bad. Sometimes it's OK to say no. > > > Vladislav> For instance, how about copy offload? How about atomic > Vladislav> writes? > > I'm actively working on copy offload. Nobody appears to be interested in > atomic writes. Otherwise I'd work on those as well. > > > Vladislav> Why was it needed to create special blk integrity interface > Vladislav> with the only end user - SCSI? > > Simple. Because we did not want to interleave data and PI 512+8+512+8 > neither in memory, nor at DMA time. It can similarly be done in SCSI-like interface without need for any middleman. > Furthermore, the ATA EPP proposal > was still on the table so I also needed to support ATA. > > And finally, NVM Express uses the blk_integrity interface as well. > > > Vladislav> The block layer keeps repeating SCSI. So, maybe, after all, > Vladislav> it's better to acknowledge that direct usage of SCSI without > Vladislav> any intermediate layers and translations is more productive? > Vladislav> And for those minors not using SCSI internally, translate > Vladislav> from SCSI to their internal commands? Creating and filling > Vladislav> CDB fields for most cases isn't anyhow harder, than creating > Vladislav> and feeling bio fields. > > This is quite possibly the worst idea I have heard all week. > > As it stands it's a headache for the disk ULD driver to figure out which > of the bazillion READ/WRITE variants to send to a SCSI/ATA device. What > makes you think that an application or filesystem would be better > equipped to make that call? > > See also: WRITE SAME w/ zeroes vs. WRITE SAME w/ UNMAP vs. UNMAP > > See also: EXTENDED COPY vs. the PROXY command set > > See also: USB-ATA bridge chips > > You make it sound like all the block layer does is filling out > CDBs. Which it doesn't in fact have anything to do with at all. > > When you are talking about CDBs we're down in the SBC/SSC territory. > Which is such a tiny bit of what's going on. We have transports, we have > SAM, we have HBA controller DMA constraints, system DMA constraints, > buffer bouncing, etc. There's a ton of stuff that needs to happen before > the CDB and the data physically reach the storage. > > You seem to be advocating that everything up to the point where the > device receives the command is in the way. Well, by all means. Why limit > ourselves to the confines of SCSI? Why not get rid of POSIX > read()/write(), page cache, filesystems and let applications speak > ST-506 directly? > > I know we're doing different things. My job is to make a general purpose > operating system with interfaces that make sense to normal applications. > That does not preclude special cases where it may make sense to poke at > the device directly. For testing purposes, for instance. But I consider > it a failure when we start having applications that know about hardware > intricacies, cylinders/heads/sectors, etc. That road leads straight to > the 1980s... What you mean is true, but my point is that this abstraction is better to be done in SCSI, i.e. SAM, manner. Now need to write fields inside of CDBs, it would be pretty inconvenient ;). But CDBs fields can be fields in some scsi_io structure. Exact opcodes can be easily abstracted to be filled on the last stage, where end CDB is constructed from those fields. Problem with block abstraction is that it is the least common denominator of all block devices capabilities, hence advanced capabilities, available only some class of devices, are automatically become "impossible". Hence, it would be more productive instead to use the most capable abstraction, which is SAM. In this abstraction there's no need to reinvent complex interfaces and write complex middleman code for every advanced capability. All advanced capabilities there are available by definition, if supported by underlying hardware. That's my point. POSIX is for simple applications, for which read()/write() calls are sufficient. They are outside of our discussions. But advanced applications need more. I know plenty of applications issuing direct SCSI commands, but how many can you name applications using block interface (bsg)? I can recall only one quite relatively used Linux specific library. That's all. This interface is not demanded by applications. Vlad -- 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 0/3] palmas usb driver
Hi Felipe, On Tuesday 28 May 2013 11:05 PM, Felipe Balbi wrote: On Fri, May 24, 2013 at 08:01:33PM +0530, Kishon Vijay Abraham I wrote: This patch series adds driver for palmas usb which is used to detect attach/detach events of usb device and usb host. [PATCH v5 2/3] extcon: Palmas Extcon Driver which was sent previously is added in this patch series itself. The revision history is added in the patch comments section. A checkpatch warning "WARNING: static const char * array should probably be static const char * const"is ignored since it introduces a compilation warning. Graeme Gregory (2): drivers: regulator: palmas: add an API to set/clear the switch bit on SMPS10 extcon: Palmas Extcon Driver Kishon Vijay Abraham I (1): usb: dwc3: use extcon fwrk to receive connect/disconnect notification There were some comments to this series, what will happen with it ? Any new versions coming ? I've already sent new versions. Palmas Extcon Driver is already queued in extcon-next. Chanwoo can take this patch in his tree after your ACK. [PATCH v2] usb: dwc3: use extcon fwrk to receive connect/disconnect notification. Thanks Kishon -- 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: build warning after merge of the final tree
From: Stephen Rothwell
Date: Wed, 29 May 2013 15:29:15 +1000
> Introduced by commit 1a37e412a022 ("net: Use 16bits for *_headers fields
> of struct skbuff") from the net-next tree.
Simon just posted fixes for this, sorry about that.
--
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/
linux-next: Tree for May 29
Hi all, Changes since 20130528: The trivial tree gained a conflict against the net-next tree. The xen-arm tree gained a build failure so I used the version from next-20130528. The staging tree gained a conflict against the net-next tree. The net-next tree added the following build warning for some configurations: In file included from include/net/tcp.h:44:0, from net/core/sock.c:139: include/net/inet_ecn.h: In function 'INET_ECN_set_ce': include/net/inet_ecn.h:137:50: warning: comparison between pointer and integer [enabled by default] include/net/inet_ecn.h:142:52: warning: comparison between pointer and integer [enabled by default] I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" as mentioned in the FAQ on the wiki (see below). You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (minus CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc, sparc64 and arm defconfig. These builds also have CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and CONFIG_DEBUG_INFO disabled when necessary. Below is a summary of the state of the merge. We are up to 227 trees (counting Linus' and 31 trees of patches pending for Linus' tree), more are welcome (even if they are currently empty). Thanks to those who have contributed, and to those who haven't, please do. Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. There is a wiki covering stuff to do with linux-next at http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (58f8bbd Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux) Merging fixes/master (0279b3c Merge branch 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging kbuild-current/rc-fixes (ad06156 kbuild: Don't assume dts files live in arch/*/boot/dts) Merging arc-current/for-curr (e4aa937 Linux 3.10-rc3) Merging arm-current/fixes (f27d6e1 ARM: 7729/1: vfp: ensure VFP_arch is non-zero when VFP is not supported) Merging m68k-current/for-linus (37c14e8 m68k: Update defconfigs for v3.9) Merging powerpc-merge/merge (f1dd153 powerpc/pseries: Make 32-bit MSI quirk work on systems lacking firmware support) Merging sparc/master (de9c9f8 Merge tag 'remoteproc-3.10' of git://git.kernel.org/pub/scm/linux/kernel/git/ohad/remoteproc) Merging net/master (f96ef98 ipv4: fix redirect handling for TCP packets) Merging ipsec/master (da241ef Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net) Merging sound-current/for-linus (d47333d ALSA: usb-6fire: Modify firmware version check) Merging pci-current/for-linus (f3f0117 Revert "x86/pci/mrst: Use configuration mechanism 1 for 00:00.0, 00:02.0, 00:03.0") Merging wireless/master (add295a ath9k: use correct OTP register offsets for AR9550) Merging driver-core.current/driver-core-linus (e4aa937 Linux 3.10-rc3) Merging tty.current/tty-linus (e4aa937 Linux 3.10-rc3) Merging usb.current/usb-linus (e4aa937 Linux 3.10-rc3) Merging staging.current/staging-linus (e4aa937 Linux 3.10-rc3) Merging char-misc.current/char-misc-linus (e4aa937 Linux 3.10-rc3) Merging input-current/for-linus (c73a1af Input: wacom - add an eraser to DTH2242/DTK2241) Merging md-current/for-linus (32f9f57 MD: ignore discard request for hard disks of hybid raid1/raid10 array) Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix) Merging crypto-current/master (de614e5 crypto: sha256_ssse3 - fix stack corruption with SSSE3 and AVX implementations) Merging ide/master (bf6b438 ide: gayle: use module_platform_driver_probe()) Merging dwmw2/master (5950f08 pcmcia: remove RPX board stuff) Merging sh-current/sh-fixes-for-linus (4403310 SH: Convert out[bwl] macros to inline functions) Merging irqdomain-current/irqdomain/merge (a0d27
Re: [PATCH v6 1/9] drivers: phy: add generic PHY framework
Hi, On Wednesday 29 May 2013 04:07 AM, Sylwester Nawrocki wrote: Hi Kishon, On 04/29/2013 12:03 PM, Kishon Vijay Abraham I wrote: The PHY framework provides a set of APIs for the PHY drivers to create/destroy a PHY and APIs for the PHY users to obtain a reference to the PHY with or without using phandle. For dt-boot, the PHY drivers should also register *PHY provider* with the framework. PHY drivers should create the PHY by passing id and ops like init, exit, power_on and power_off. This framework is also pm runtime enabled. The documentation for the generic PHY framework is added in Documentation/phy.txt and the documentation for dt binding can be found at Documentation/devicetree/bindings/phy/phy-bindings.txt Signed-off-by: Kishon Vijay Abraham I Thanks for working on this. For the record, I plan to give this a try in the end of this week, with my simple MIPI CSI/DSI PHY driver. I might have some more comments then. For now just couple of remarks after reading the documentation. Thanks for reviewing. I'll wait for your comments before posting the next version. Thanks Kishon -- 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: [RFC PATCH v2 00/15][Sorted-buddy] mm: Memory Power Management
On 05/29/2013 01:38 AM, Phillip Susi wrote: > > On 4/19/2013 3:12 AM, Srivatsa S. Bhat wrote: >> But going further, as I had mentioned in my TODO list, we can be >> smarter than this while doing compaction to evacuate memory regions >> - we can choose to migrate only the active pages, and leave the >> inactive pages alone. Because, the goal is to actually consolidate >> the *references* and not necessarily the *allocations* themselves. > > That would help with keeping references compact to allow use of the > low power states, but it would also be nice to keep allocations > compact, and completely power off a bank of ram with no allocations. > That is a very good point, thanks! But one of the differences we have to keep in mind is that powering off a bank requires intervention from the OS (ie., OS should initiate the power-off, because we lose the contents on power-off) whereas going to lower power states can be mostly done automatically by the hardware (because it is content-preserving). But powering-off unused banks of RAM (using techniques such as PASR - Partial Array Self Refresh) can give us more power-savings than just entering lower power states. So yes, keeping allocations consolidated has that additional advantage. And the sorted-buddy design of the page allocator helps us achieve that. Thanks a lot for your inputs, Phillip! Regards, Srivatsa S. Bhat -- 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] md: bcache: io.c: fix a potential NULL pointer dereference
On Tue, May 28, 2013 at 05:20:41PM -0700, Kent Overstreet wrote: > On Tue, May 28, 2013 at 12:31:15AM -0700, Kumar Amit Mehta wrote: > > bio_alloc_bioset returns NULL on failure. This fix adds a missing check > > for potential NULL pointer dereferencing. > > Whoops, that's definitely a bug. Thanks, applied. > > How'd you find it? Using smatch[1] [1] http://smatch.sourceforge.net/ -- 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: EXYNOS: Update defconfig for Arndale and Origen board
On Tue, May 28, 2013 at 8:59 PM, Tushar Behera wrote: > The patches are at [1]. FWIW, a cgit/gitweb link is easier to follow when you're reading an email. Anyway, found the patches. > There are a total of 6 patches on top of > v3.10-rc3. 3 of them (a, b, d) are queued for 3.10-rc4 and another patch > (c) is just a defconfig hack to get Arndale booting. Remaining 2 patches > (e, f) are required to reset the hub during EHCI initialization. Huh, I thought you said that (c) wasn't needed when I posted the defconfig update. It'd be nice to see the code fixed to handle this case instead of Linaro carrying a patch like this though. I.e. make it able to deselect the uart, or make it tied to DEBUG_LL like on other platforms instead of having a separate config for this. > a. ARM: exynos: defconfig update > b. ARM: EXYNOS: Update defconfig for Arndale and Origen board > c. [TEMP] ARM: EXYNOS: Set low-level UART port to 2 > d. ARM: dts: Enabling samsung-usb2phy driver for exynos5250 > e. usb: ehci-s5p: add the HSIC port initialization > f. ARM: dts: Add USB gpio entries for Arndale board > > I am not sure whether such kind of board-specific patches (e, f) are > appreciated in the drivers. But that is all we need to get USB and > Ethernet to work on v3.10-rc3 kernel. I've come across a similar situation with wifi reset sequence on the chromebook. On the product kernel we added some code to the board file to deal with it, but if we keep doing that things will grow out of hand. I don't know if it'll be unpopular, but I think it's time to start a drivers/platform/arm for these kind of things, and have those drivers probe on the system compatible value, similar to how x86 does it (with DMI tables). At least that's my plan for approaching the wifi reset/power-on sequence on the Chromebook. I hope to have patches in not all that long... Likewise, the hub reset/enable code doesn't have to go with the USB driver, right? I.e. if you cycle reset/enable on the hub after the host and phy is configured, you'll still have a working setup? -Olof -- 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/
linux-next: build warning after merge of the final tree
Hi all,
After merging the final tree, today's linux-next build (powerpc
ppc44x_defconfig, i386 defconfig, sparc32 defconfig) produced these
warning:
In file included from /scratch/sfr/next/include/net/tcp.h:44:0,
from /scratch/sfr/next/net/core/sock.c:139:
/scratch/sfr/next/include/net/inet_ecn.h: In function 'INET_ECN_set_ce':
/scratch/sfr/next/include/net/inet_ecn.h:137:50: warning: comparison between
pointer and integer [enabled by default]
/scratch/sfr/next/include/net/inet_ecn.h:142:52: warning: comparison between
pointer and integer [enabled by default]
I got lots of these :-(
Introduced by commit 1a37e412a022 ("net: Use 16bits for *_headers fields
of struct skbuff") from the net-next tree.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpe7M0hy9uh4.pgp
Description: PGP signature
ftrace calltrace when boot through kexec
Hello, When I reboot a preempt_rt 3.4 kernel with cortex a15 tc2 board thru kexec, I got below calltrace appeared: [ cut here ] WARNING: at kernel/trace/ftrace.c:1584 ftrace_bug+0x1e0/0x224() Modules linked in: [] (unwind_backtrace+0x0/0x104) from [] (dump_stack+0x20/0x24) [] (dump_stack+0x20/0x24) from [] (warn_slowpath_common+0x64/0x74) [] (warn_slowpath_common+0x64/0x74) from [] (warn_slowpath_null+0x2c/0x34) [] (warn_slowpath_null+0x2c/0x34) from [] (ftrace_bug+0x1e0/0x224) [] (ftrace_bug+0x1e0/0x224) from [] (ftrace_process_locs+0x880/0x930) [] (ftrace_process_locs+0x880/0x930) from [] (ftrace_init+0xb4/0x194) [] (ftrace_init+0xb4/0x194) from [] (start_kernel+0x338/0x348) [] (start_kernel+0x338/0x348) from [<80008054>] (0x80008054) ---[ end trace af5b256dd27bb7ab ]--- ftrace failed to modify [] platform_cpu_kill+0x10/0x1c actual: 00:40:bd:e8 Add notrace before platform_cpu_kill can workaround this calltrace, but it is weird that this problem can't reproduce in another cortex-a9 (xilinx-zynq) board, could someone give some hints about this? Thanks. Regards, Xiao -- 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: [RFC v2 0/3][TESTS] LAB: Support for Legacy Application Booster governor - tests results
On 29 May 2013 03:18, Rafael J. Wysocki wrote: > On Tuesday, May 28, 2013 03:26:25 PM Lukasz Majewski wrote: >> Hi Viresh, Rafael, >> >> > On Tuesday, May 28, 2013 03:14:26 PM Viresh Kumar wrote: >> > I'm not sure about that. On x86 boost will be used with all >> > governors if enabled (as currently defined in acpi-cpufreq). >> >> All governors can benefit from the overclocking code. Yeah. >> > Also it looks like this depends on the driver too, because if the >> > driver doesn't have "turbo" frequencies, the governor won't be able >> > use "turbo" anyway. Yes. >> > So first, it would make sense to use a per-driver "boost" attribute >> > indicating whether or not the given driver should present any "turbo" >> > frequencies to the governor. @Lukasz: So, you need to add another field in struct cpufreq_driver, which will be called "turbo_mode" or something better. >> Now I'm using a device tree's cpufreq section (defined at >> exynos4412-redwood.dts) with overclocking = "okay" attribute defined. >> Then, on this basis, we could decide at cpufreq init time if we will >> export any overclocking related sysfs entries (or init overclocking at >> all). It would assure clearer code. > > Well, what about users? Don't you want them to be able to decide whether > or not to use "turbo"? I believe Lukasz was saying that we can have two levels of enabling it.. Firstly the driver can say if it supports turbo_mode or not and so will register cpufreq_driver with appropriate parameters.. Now if turbo_mode == true, then sysfs entry will be created by cpufreq core which users can enable/disable... And this is what I had in mind too. >> I think that global cpufreq device tree attribute shall be defined. > > What do you mean by "device tree attribute"? If you mean FDTs as used by > ARM for system configuration description, that wouldn't be portable, because > DTs aren't used for that on the (majority of) x86 systems. So, drivers should pass correct value in boost_mode in struct cpufreq_driver. They get it from DT or is hard coded doesn't matter at all to the core. But yes getting a single name for DT bindings would be good. We should use the same name at that place too: turbo_mode >> The overclocking will be an integral part of the cpufreq framework. > > Well, to be precise, I was thinking about moving the management of the > /sys/devices/system/cpu/cpufreq/boost attribute from acpi-cpufreq to the > code so that other drivers may use it too. Does that make sense to you? Obviously yes. The sysfs related code from acpi-cpufreq should be moved to cpufreq.c and will be functional once cpufreq_driver has boost_mode set as true. >> > Second, I'm not sure if an additional knob for the governor is >> > necessary. It may just use the turbo frequencies if available (and >> > if the governor cannot use them, it simply won't use them). >> >> I cannot agree. It is welcome to be able to enable/disable the feature >> when needed. Turbo frequencies shall not be "available" for use all the >> time. Yes, you can disable that from userspace once your driver said: "I support turbo mode".. -- 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 0/3] proc: first_tid() fix/cleanup
Oleg Nesterov writes: > Hello. > > next_thread() should be avoided, probably next_tid() is the > only "valid" user. > > But now we have another reason to avoid (and probably even kill) > it, we are going to replace or fix while_each_thread(), almost > every lockless usage is wrong. > > I was going to send more changes, but this initial series nearly > killed me. And I think first_tid() needs another cleanup, ->f_pos > truncation doesn't look nice, tomorrow. I have made some comments but overall this looks like a good set of cleanups. Reviewed-by: "Eric W. Biederman" As for f_pos truncation if you want you can safely check if f_pos is greater than PID_MAX_LIMIT as we will never more threads than we have pids. Eric -- 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: [RFC PATCHv4 0/6] arm: Initial TI-Nspire support
On 27/05/2013, at 8:31 PM, Arnd Bergmann wrote: > On Monday 27 May 2013, Daniel Tang wrote: >>> The one remaining bit that sticks out is the clcd platform data. As I >>> said before, I won't require you to convert that to DT in order to >>> get your code merged, but I'd also really like to see that happen, >>> as we will also need that to get rid of auxdata on the ARM reference >>> platforms (integrator, versatile, realview, vexpress). >> >> How would you like me to convert the platform data to DT? AFAIK, the clcd >> driver isn't aware of DT so the only way is to use the AUXDATA right now. > > Linus Walleij mentioned on IRC that Pawel Moll already posted a series > that adds DT support for clcd: > > http://lists.freedesktop.org/archives/dri-devel/2013-April/037519.html > > The series does a few more things, but you can probbly split out the > parts you need and base on that. Would it be fine if I waited until CLCD DT patch gets into mainline instead? > > Arnd Cheers, Daniel Tang -- 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 updated] drivers/base: Use attribute groups to create sysfs memory files
Update the sysfs memory code to create/delete files at the time of device
and subsystem registration.
The current code creates files in the root memory directory explicitly
through
the use of init_* routines. The files for each memory block are created and
deleted explicitly using the mem_[create|delete]_simple_file macros.
This patch creates attribute groups for the memory root files and files in
each memory block directory so that they are created and deleted implicitly
at subsys and device register and unregister time.
This did necessitate moving the register_memory() routine and update
it to set the dev.groups field.
Signed-off-by: Nathan Fontenot
Updated to apply cleanly to rc2.
Please cc me on responses/comments.
---
drivers/base/memory.c | 143
+-
1 file changed, 62 insertions(+), 81 deletions(-)
Index: linux/drivers/base/memory.c
===
--- linux.orig/drivers/base/memory.c2013-05-28 22:53:58.0 -0500
+++ linux/drivers/base/memory.c 2013-05-28 22:56:49.0 -0500
@@ -77,22 +77,6 @@
kfree(mem);
}
-/*
- * register_memory - Setup a sysfs device for a memory block
- */
-static
-int register_memory(struct memory_block *memory)
-{
- int error;
-
- memory->dev.bus = &memory_subsys;
- memory->dev.id = memory->start_section_nr / sections_per_block;
- memory->dev.release = memory_block_release;
-
- error = device_register(&memory->dev);
- return error;
-}
-
unsigned long __weak memory_block_size_bytes(void)
{
return MIN_MEMORY_BLOCK_SIZE;
@@ -371,11 +355,6 @@
static DEVICE_ATTR(phys_device, 0444, show_phys_device, NULL);
static DEVICE_ATTR(removable, 0444, show_mem_removable, NULL);
-#define mem_create_simple_file(mem, attr_name) \
- device_create_file(&mem->dev, &dev_attr_##attr_name)
-#define mem_remove_simple_file(mem, attr_name) \
- device_remove_file(&mem->dev, &dev_attr_##attr_name)
-
/*
* Block size attribute stuff
*/
@@ -388,12 +367,6 @@
static DEVICE_ATTR(block_size_bytes, 0444, print_block_size, NULL);
-static int block_size_init(void)
-{
- return device_create_file(memory_subsys.dev_root,
- &dev_attr_block_size_bytes);
-}
-
/*
* Some architectures will have custom drivers to do this, and
* will not need to do it from userspace. The fake hot-add code
@@ -429,17 +402,8 @@
out:
return ret;
}
-static DEVICE_ATTR(probe, S_IWUSR, NULL, memory_probe_store);
-static int memory_probe_init(void)
-{
- return device_create_file(memory_subsys.dev_root, &dev_attr_probe);
-}
-#else
-static inline int memory_probe_init(void)
-{
- return 0;
-}
+static DEVICE_ATTR(probe, S_IWUSR, NULL, memory_probe_store);
#endif
#ifdef CONFIG_MEMORY_FAILURE
@@ -485,23 +449,6 @@
static DEVICE_ATTR(soft_offline_page, S_IWUSR, NULL,
store_soft_offline_page);
static DEVICE_ATTR(hard_offline_page, S_IWUSR, NULL,
store_hard_offline_page);
-
-static __init int memory_fail_init(void)
-{
- int err;
-
- err = device_create_file(memory_subsys.dev_root,
- &dev_attr_soft_offline_page);
- if (!err)
- err = device_create_file(memory_subsys.dev_root,
- &dev_attr_hard_offline_page);
- return err;
-}
-#else
-static inline int memory_fail_init(void)
-{
- return 0;
-}
#endif
/*
@@ -546,6 +493,41 @@
return find_memory_block_hinted(section, NULL);
}
+static struct attribute *memory_memblk_attrs[] = {
+ &dev_attr_phys_index.attr,
+ &dev_attr_end_phys_index.attr,
+ &dev_attr_state.attr,
+ &dev_attr_phys_device.attr,
+ &dev_attr_removable.attr,
+ NULL
+};
+
+static struct attribute_group memory_memblk_attr_group = {
+ .attrs = memory_memblk_attrs,
+};
+
+static const struct attribute_group *memory_memblk_attr_groups[] = {
+ &memory_memblk_attr_group,
+ NULL,
+};
+
+/*
+ * register_memory - Setup a sysfs device for a memory block
+ */
+static
+int register_memory(struct memory_block *memory)
+{
+ int error;
+
+ memory->dev.bus = &memory_subsys;
+ memory->dev.id = memory->start_section_nr / sections_per_block;
+ memory->dev.release = memory_block_release;
+ memory->dev.groups = memory_memblk_attr_groups;
+
+ error = device_register(&memory->dev);
+ return error;
+}
+
static int init_memory_block(struct memory_block **memory,
struct mem_section *section, unsigned long
state)
{
@@ -569,16 +551,6 @@
mem->phys_device = arch_get_memory_phys_device(start_pfn);
ret = register_memory(mem);
- if (!ret)
- ret = mem_create_simple_file(mem, phys_index);
- if (!ret)
- ret = mem_create_simple_file(mem, end_phys_index);
- if (!ret)
- ret = mem_create_simple_file(mem,
Re: [RFC PATCHv4 1/6] arm: TI-Nspire platform code
On 28/05/2013, at 1:15 AM, Arnd Bergmann wrote: > On Monday 27 May 2013, Daniel Tang wrote: >> Before any peripheral is accessed. I.e. before the clocksource and irqchip >> drivers. > > The irqchip comes first, and by that time, you can actually call > of_iomap(). > >> The write to the port is supposed to ensure all mmio peripherals can be >> accessed. Without it, access to certain peripherals will result in >> undefined reads or ignored writes. >> >> On second thoughts, would this actually be the job of the boot loader? > > Doing it in the boot loader would certainly simplify things. I wonder > about the dynamic aspects of power management though: It might be > better to expose the individual bits of this register through a proper > driver. The boot loader can start out enabling everything, but then > you turn off everything that is not needed when that driver gets > loaded. That's the idea for the long term. For now though, I'll probably just let the bootloader enable everything and work on a proper driver for power management later. > > I'm still not sure what the register actually does: Does it > control reset lines, clock signals, voltage regulators or something > else? These things all have their own subsystems, and then there > is also the power domain framework. To be perfectly honest, I'm not too sure. The documentation for the TI-Nspire is all gathered from reverse engineering and all it says is that register "disables bus access to peripherals". > > Arnd Cheers, Daniel Tang-- 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] rcu: fix a race in hlist_nulls_for_each_entry_rcu macro
On Tue, 2013-05-28 at 18:31 -0700, Paul E. McKenney wrote:
> On Tue, May 28, 2013 at 05:34:53PM -0700, Eric Dumazet wrote:
> > On Tue, 2013-05-28 at 13:10 +0400, Roman Gushchin wrote:
> > > On 28.05.2013 04:12, Eric Dumazet wrote:
> >
> > > > Adding a barrier() is probably what we want.
> > >
> > > I agree, inserting barrier() is also a correct and working fix.
> >
> > Yeah, but I can not find a clean way to put it inside the "for (;;)"
> >
> > for (barrier();;) ->
> >
> > error: expected expression before ‘__asm__’
> >
> > No user currently does :
> >
> > if (condition)
> > hlist_nulls_for_each_entry_rcu(tpos, pos, head, member)
> >
> > But who knows...
>
> I still have my earlier question, but I suggest "({ barrier(); XXX })"
> to put the barrier into the for loop, either in the second or third
> clause, where XXX was the original second or third clause.
>
>
Hmm, it doesn't work, I wanted to replace :
barrier();
for (expr1 ; expr2; expr3) {
by :
for ( some_clever_thing ; expr2; expr3) {
So barrier() should not be in second or third clause : it must be done
once and before "expr1".
Not a big deal anyway, we're not adding new
hlist_nulls_for_each_entry_rcu() users :)
About your earlier question, I really don't know why compiler would
cache a memory read if we explicitly use barrier() to prevent this from
happening.
BTW Roman patch generates a double load as in :
2cb1: 49 8b 07mov(%r15),%rax
2cb4: 49 8b 07mov(%r15),%rax
...
2ea2: e8 f9 dc ff ff callq ba0
2ea7: 8b 0c 24mov(%rsp),%ecx
2eaa: e9 02 fe ff ff jmpq 2cb1
because of ACCESS_ONCE() used twice, once explicitly in
hlist_nulls_for_each_entry_rcu(), and once in rcu_dereference_raw()
While barrier();ptr = rcu_dereference(X); does generate a single load.
--
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 04/21] Generic percpu refcounting
Kent Overstreet writes: > On Wed, May 15, 2013 at 10:37:20AM -0700, Tejun Heo wrote: >> Can you please expand it on a bit and, more importantly, describe in >> what limits, it's safe? This should be safe as long as the actual sum >> of refcnts given out doesn't overflow the original type, right? > > Precisely. > >> It'd be great if that is explained clearly in more intuitive way. The >> only actual explanation above is "modular arithmatic is commutative" >> which is a very compact way to put it and I really think it deserves >> an easier explanation. > > I'm not sure I know of any good way of explaining it intuitively, but > here's this at least... > > * (More precisely: because moduler arithmatic is commutative the sum of all > the > * pcpu_count vars will be equal to what it would have been if all the gets > and > * puts were done to a single integer, even if some of the percpu integers > * overflow or underflow). This seems intuitively obvious, so I wouldn't sweat it too much. What goes up, has to come down somewhere. >> > > Are we sure this is enough? 1<<31 is a fairly large number but it's >> > > just easy enough to breach from time to time and it's gonna be hellish >> > > to reproduce / debug when it actually overflows. Maybe we want >> > > atomic64_t w/ 1LLU << 63 bias? Or is there something else which >> > > guarantees that the bias can't over/underflow? >> > >> > Well, it has the effect of halving the usable range of the refcount, >> > which I think is probably ok - the thing is, the range of an atomic_t >> > doesn't really correspond to anything useful on 64 bit machines so if >> > you're concerned about overflow you probably need to be using an >> > atomic_long_t. That is, if 32 bits is big enough 31 bits probably is >> > too. >> >> I'm not worrying about the total refcnt overflowing 31 bits, that's >> fine. What I'm worried about is the percpu refs having systmetic >> drift (got on certain cpus and put on others), and the total counter >> being overflowed while percpu draining is in progress. To me, the >> problem is that the bias which tags that draining in progress can be >> overflown by percpu refs. The summing can be the same but the tagging >> should be put where summing can't overflow it. It'd be great if you >> can explain in the comment in what range it's safe and why, because >> that'd make the limits clear to both you and other people reading the >> code and would help a lot in deciding whether it's safe enough. > > (This is why I initially didn't (don't) like the bias method, it makes > things harder to reason about). > > The fact that the counter is percpu is irrelevant w.r.t. the bias; we > sum all the percpu counters up before adding them to the atomic counter > and subtracting the bias, so when we go to add the percpu counters it's > no different from if the percpu counter was a single integer all along. > > So there's only two counters we're adding together; there's the percpu > counter (just think of it as a single integer) that we started out > using, but then at some point in time we start applying the gets and > puts to the atomic counter. > > Note that there's no systemic drift here; at time t all the gets and > puts were happening to one counter, and then at time t+1 they switch to > a different counter. > > We know the sum of the counters will be positive (again, because modular > arithmatic is still commutative; when we sum the counters it's as if > there was a single counter all along) but that doesn't mean either of > the individual counters can't be negative. > > (Actually, unless I'm mistaken in this version the percpu counter can > never go negative - it definitely could with dynamic percpu allocation, > as you need a atomic_t -> percpu transition when the atomic_t was > 0 > for the percpu counter to go negative; but in this version we start out > using the percpu counters and the atomic_t 0 (ignoring for the moment > the bias and the initial ref). > > So, the sum must be positive but the atomic_t could be negative. How > negative? > > We can't do a get() to the percpu counters after we've seen that the ref > is no longer in percpu mode - so after we've done one put to the > atomic_t we can do more puts to atomic_t (or gets to the atomic_t) but > we can't do a get to the percpu counter. > > And we can't do more puts than there have been gets - because the sum > can't be negative. So the most puts() we can do at any given time is the > real count, or sum of the percpu ref and atomic_t. > > Therefore, the amount the atomic_t can go negative is bounded by the > maximum value of the refcount. > > So if we say arbitrarily that the maximum legal value of the refcount is > - say - 1U << 31, then the atomic_t will always be greater than > -((int) (1U << 31)). > > So as long as the total number of outstanding refs never exceeds the > bias we're fine. Yes. We should note the 31 bit limit somewhere. We could WARN_ON() if count is >= BIAS in percpu_ref_
[PATCH V2] cpufreq: Raname index as driver_data in cpufreq_frequency_table
"Index" field of struct cpufreq_frequency_table was never index and isn't used
at all by cpufreq core. And is only useful for cpufreq drivers for their
personal use.
Many people now a days blindly set it in ascending order with the assumption
that core is using it for some work.
This patch renames it to "driver_data" as that's what its purpose it. All users
of the same are fixed too.
Signed-off-by: Viresh Kumar
---
V1->V2:
- rename data as driver_data, as suggested by Rafael.
Documentation/cpu-freq/cpu-drivers.txt | 10 +-
arch/arm/mach-davinci/da850.c | 8 +-
arch/arm/mach-s3c24xx/cpufreq-utils.c | 2 +-
arch/arm/mach-s3c24xx/cpufreq.c| 4 +-
arch/arm/mach-s3c24xx/pll-s3c2410.c| 54 +-
arch/arm/mach-s3c24xx/pll-s3c2440-1200.c | 54 +-
arch/arm/mach-s3c24xx/pll-s3c2440-16934400.c | 110 ++---
arch/arm/mach-shmobile/clock-sh7372.c | 6 +-
arch/arm/plat-samsung/include/plat/cpu-freq-core.h | 2 +-
arch/mips/loongson/lemote-2f/clock.c | 3 +-
arch/powerpc/platforms/pasemi/cpufreq.c| 5 +-
drivers/base/power/opp.c | 4 +-
drivers/cpufreq/acpi-cpufreq.c | 6 +-
drivers/cpufreq/blackfin-cpufreq.c | 10 +-
drivers/cpufreq/e_powersaver.c | 8 +-
drivers/cpufreq/freq_table.c | 26 ++---
drivers/cpufreq/ia64-acpi-cpufreq.c| 2 +-
drivers/cpufreq/kirkwood-cpufreq.c | 2 +-
drivers/cpufreq/longhaul.c | 16 +--
drivers/cpufreq/loongson2_cpufreq.c| 2 +-
drivers/cpufreq/p4-clockmod.c | 4 +-
drivers/cpufreq/powernow-k6.c | 8 +-
drivers/cpufreq/powernow-k7.c | 16 +--
drivers/cpufreq/powernow-k8.c | 18 ++--
drivers/cpufreq/ppc_cbe_cpufreq.c | 4 +-
drivers/cpufreq/pxa2xx-cpufreq.c | 8 +-
drivers/cpufreq/pxa3xx-cpufreq.c | 4 +-
drivers/cpufreq/s3c2416-cpufreq.c | 2 +-
drivers/cpufreq/s3c64xx-cpufreq.c | 2 +-
drivers/cpufreq/sc520_freq.c | 2 +-
drivers/cpufreq/sparc-us2e-cpufreq.c | 12 +--
drivers/cpufreq/sparc-us3-cpufreq.c| 8 +-
drivers/cpufreq/spear-cpufreq.c| 4 +-
drivers/cpufreq/speedstep-centrino.c | 8 +-
drivers/mfd/db8500-prcmu.c | 10 +-
drivers/sh/clk/core.c | 4 +-
include/linux/cpufreq.h| 2 +-
37 files changed, 223 insertions(+), 227 deletions(-)
diff --git a/Documentation/cpu-freq/cpu-drivers.txt
b/Documentation/cpu-freq/cpu-drivers.txt
index a3585ea..19fa98e 100644
--- a/Documentation/cpu-freq/cpu-drivers.txt
+++ b/Documentation/cpu-freq/cpu-drivers.txt
@@ -186,7 +186,7 @@ As most cpufreq processors only allow for being set to a
few specific
frequencies, a "frequency table" with some functions might assist in
some work of the processor driver. Such a "frequency table" consists
of an array of struct cpufreq_frequency_table entries, with any value in
-"index" you want to use, and the corresponding frequency in
+"driver_data" you want to use, and the corresponding frequency in
"frequency". At the end of the table, you need to add a
cpufreq_frequency_table entry with frequency set to CPUFREQ_TABLE_END. And
if you want to skip one entry in the table, set the frequency to
@@ -214,10 +214,4 @@ int cpufreq_frequency_table_target(struct cpufreq_policy
*policy,
is the corresponding frequency table helper for the ->target
stage. Just pass the values to this function, and the unsigned int
index returns the number of the frequency table entry which contains
-the frequency the CPU shall be set to. PLEASE NOTE: This is not the
-"index" which is in this cpufreq_table_entry.index, but instead
-cpufreq_table[index]. So, the new frequency is
-cpufreq_table[index].frequency, and the value you stored into the
-frequency table "index" field is
-cpufreq_table[index].index.
-
+the frequency the CPU shall be set to.
diff --git a/arch/arm/mach-davinci/da850.c b/arch/arm/mach-davinci/da850.c
index 4d69338..a0d4f60 100644
--- a/arch/arm/mach-davinci/da850.c
+++ b/arch/arm/mach-davinci/da850.c
@@ -1004,7 +1004,7 @@ static const struct da850_opp da850_opp_96 = {
#define OPP(freq) \
{ \
- .index = (unsigned int) &da850_opp_##freq, \
+ .driver_data = (unsigned int) &da850_opp_##freq,\
.frequency = freq * 1000, \
}
@@ -1016,7 +1016,7 @@ static struct cpufreq_frequency_table da850_freq_table[]
= {
OPP(200),
OPP(96),
{
- .in
Re: [PATCH 3/3] proc: simplify proc_task_readdir/first_tid paths
Oleg Nesterov writes:
> proc_task_readdir() does not really need "leader", first_tid()
> has to revalidate it anyway. Just pass proc_pid(inode) to
> first_tid() instead, it can do pid_task(PIDTYPE_PID) itself
> and read ->group_leader only if necessary.
>
> Note: I am not sure proc_task_readdir() really needs the initial
> -ENOENT check, but this is what the current code does.
This looks like a nice cleanup.
We would need either -ENOENT or a return of 0 and an empty directory at
the least. We need the check so that empty directories don't have "."
and ".." entries.
Eric
> Signed-off-by: Oleg Nesterov
> ---
> fs/proc/base.c | 46 --
> 1 files changed, 16 insertions(+), 30 deletions(-)
>
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index bed1096..dbc4dae 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -3173,34 +3173,35 @@ out_no_task:
> * In the case of a seek we start with the leader and walk nr
> * threads past it.
> */
> -static struct task_struct *first_tid(struct task_struct *leader,
> - int tid, int nr, struct pid_namespace *ns)
> +static struct task_struct *first_tid(struct pid *pid, int tid,
> + int nr, struct pid_namespace *ns)
> {
> - struct task_struct *pos;
> + struct task_struct *pos, *task;
>
> rcu_read_lock();
> - /* Attempt to start with the pid of a thread */
> + task = pid_task(pid, PIDTYPE_PID);
Elegant. If we can from the task from the pid the task is hashed
and still alive when we are in the rcu critical section.
> + if (!task)
> + goto fail;
> +
> + /* Attempt to start with the tid of a thread */
> if (tid && (nr > 0)) {
> pos = find_task_by_pid_ns(tid, ns);
> - if (pos && (pos->group_leader == leader))
> + if (pos && same_thread_group(pos, task))
Sigh this reminds me we need to figure out how to kill task->pid and
task->tgid, which I assume means fixing same_thread_group.
> goto found;
> }
>
> /* If nr exceeds the number of threads there is nothing todo */
> - if (nr && nr >= get_nr_threads(leader))
> - goto fail;
> - /* It could be unhashed before we take rcu lock */
> - if (!pid_alive(leader))
> + if (nr && nr >= get_nr_threads(task))
> goto fail;
> /* If we haven't found our starting place yet start
>* with the leader and walk nr threads forward.
>*/
> - pos = leader;
> + pos = task = task->group_leader;
> do {
> if (nr-- <= 0)
> goto found;
> - } while_each_thread(leader, pos);
> + } while_each_thread(task, pos);
> fail:
> pos = NULL;
> goto out;
> @@ -3247,26 +3248,13 @@ static int proc_task_readdir(struct file * filp, void
> * dirent, filldir_t filldi
> {
> struct dentry *dentry = filp->f_path.dentry;
> struct inode *inode = dentry->d_inode;
> - struct task_struct *leader = NULL;
> struct task_struct *task;
> - int retval = -ENOENT;
> ino_t ino;
> int tid;
> struct pid_namespace *ns;
>
> - task = get_proc_task(inode);
> - if (!task)
> - goto out_no_task;
> - rcu_read_lock();
> - if (pid_alive(task)) {
> - leader = task->group_leader;
> - get_task_struct(leader);
> - }
> - rcu_read_unlock();
> - put_task_struct(task);
> - if (!leader)
> - goto out_no_task;
> - retval = 0;
> + if (!pid_task(proc_pid(inode), PIDTYPE_PID))
> + return -ENOENT;
Strictly speaking this call to pid_task needs to be in a rcu critical
section.
> switch ((unsigned long)filp->f_pos) {
> case 0:
> @@ -3289,7 +3277,7 @@ static int proc_task_readdir(struct file * filp, void *
> dirent, filldir_t filldi
> ns = filp->f_dentry->d_sb->s_fs_info;
> tid = (int)filp->f_version;
> filp->f_version = 0;
> - for (task = first_tid(leader, tid, filp->f_pos - 2, ns);
> + for (task = first_tid(proc_pid(inode), tid, filp->f_pos - 2, ns);
>task;
>task = next_tid(task), filp->f_pos++) {
> tid = task_pid_nr_ns(task, ns);
> @@ -3302,9 +3290,7 @@ static int proc_task_readdir(struct file * filp, void *
> dirent, filldir_t filldi
> }
> }
> out:
> - put_task_struct(leader);
> -out_no_task:
> - return retval;
> + return 0;
> }
>
> static int proc_task_getattr(struct vfsmount *mnt, struct dentry *dentry,
> struct kstat *stat)
--
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] rtc: rtc-hid-sensor-time: add option hctosys to set time at boot
Am 28.05.2013 21:37, schrieb John Stultz: On 05/21/2013 04:15 PM, Alexander Holler wrote: Am 22.05.2013 00:02, schrieb John Stultz: Like Andrew, I think this feels particularly hacky. Why exactly is late_init too early? (I'm unfamiliar with the rtc-hid-sensor-time driver) Currently it can be an USB device (and maybe Bluetooth or even i2c in the future, depends on hid-sensor-hub). That has some implications: (1) Initialization might need longer (or happens later) than late_init, even if everything is linked into the kernel (same problem as with a boot from USB-storage) (2) It might not even be available at boot, but it should work if a user plugs it in afterwards. (3) To accomplish (2) it should set the system time (by default) IFF nothing else did set the time. That "nothing else" in (3) is for security reasons, because no plugable HID device should be able to change the system time by default. The check if something else did set the system time can't be accomplished only by the RTC subsystem because userspace, network or whatever else is able to set the system time most likely doesn't use the RTC subsystem (or hctosys). E.g. one of those setups could be: boot hctosys (fails because of no RTC) ntpdate/rdate/date < whatever load modules (rtc-hid-sensor-time) If we would use a flag in the hctosys module then rtc-hid-sensor-time would be able to change the time (in the setup above). Using a module option which is by default off doesn't help too. Users (or even distros) which would turn it on, might forget it and systems would be at risk if no HID clock will be found at boot (but later plugged in by some blackhat). A flag in the time subsystem itself would do the trick. Such a flag might help with the problem if the RTC subsystem or the persistent clock code did set the time too. You've mentioned in another thread that you had to solve such a problem, but I'm not aware how you did that. Implementation could be as easy as a bool "time_set_at_least_once" in the timer subsystem itself (e.g. in do_settimeofday() and whatever similiar is available). If it were to be done this way, it would be good to have the RTC layer check when RTC devices are registered and call the internal hctosys functionality then (rather then just at late_init). Do you want to try to rework the patch in this way? That sounds like what Andrew Morton wanted to trick me to do. ;) Of course, if the time subsystem would offer such a flag, it would be easy to get rid of the hctosys module/driver. The RTC subsystem just could check that flag and could set the system time whenever a (usually the first) RTC driver would register (and offers a valid time). In addition that would offer the possibility to add a kernel parameter which describes the driver/module (by name) which should be used to set the time. I never really liked that rtcN from hctosys, because it doesn't really specify the RTC but depends on the order drivers get loaded. And I still like the idea to have a timewait or clockwait kernel parameter which prevents booting until the system has a valid time. Booting without having a valid time, can have serious implications (see e.g. https://lkml.org/lkml/2013/5/2/260 for which I never got feedback). I'm not totally sure I'd agree that it would be better over leaving it to userspace, but if we're going to go with an in-kernel policy for this, then it seems like a better approach then the current patch. The only way I see to do such in userspace would be with that hacky looking trick I'm using in this patch, because userspace can't reliable manage a flag "time_set_at_least_once". Regards, Alexander PS: I left out what happens on resume, because I just don't know how the kernel gets the time after a resume (and never looked at it). That might especially be tricky with a RTC which needs some time before it can offer the time itself (e.g. gps or radio) or is only available after some other subsystem like USB is available. -- 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] tuntap: forbid changing mq flag for persistent device
We currently allow changing the mq flag (IFF_MULTI_QUEUE) for a persistent device. This will result a mismatch between the number the queues in netdev and tuntap. This is because we only allocate a 1q netdevice when IFF_MULTI_QUEUE was not specified, so when we set the IFF_MULTI_QUEUE and try to attach more queues later, netif_set_real_num_tx_queues() may fail which result a single queue netdevice with multiple sockets attached. Solve this by disallowing changing the mq flag for persistent device. Bug was introduced by commit edfb6a148ce62e5e19354a1dcd9a34e00815c2a1 (tuntap: reduce memory using of queues). Reported-by: Sriram Narasimhan Cc: Michael S. Tsirkin Signed-off-by: Jason Wang --- drivers/net/tun.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/drivers/net/tun.c b/drivers/net/tun.c index f042b03..89776c5 100644 --- a/drivers/net/tun.c +++ b/drivers/net/tun.c @@ -1585,6 +1585,10 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr) else return -EINVAL; + if (!!(ifr->ifr_flags & IFF_MULTI_QUEUE) != + !!(tun->flags & TUN_TAP_MQ)) + return -EINVAL; + if (tun_not_capable(tun)) return -EPERM; err = security_tun_dev_open(tun->security); -- 1.7.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 v5] media: i2c: tvp514x: add OF support
Hi Laurent,
On Wed, May 29, 2013 at 6:52 AM, Laurent Pinchart
wrote:
> Hi Prabhakar,
>
> Thanks for the patch.
>
> On Sunday 26 May 2013 18:49:46 Prabhakar Lad wrote:
>> From: Lad, Prabhakar
>>
>> add OF support for the tvp514x driver.
>>
>> Signed-off-by: Lad, Prabhakar
>> Cc: Hans Verkuil
>> Cc: Laurent Pinchart
>> Cc: Mauro Carvalho Chehab
>> Cc: Guennadi Liakhovetski
>> Cc: Sylwester Nawrocki
>> Cc: Sakari Ailus
>> Cc: Grant Likely
>> Cc: Rob Herring
>> Cc: Rob Landley
>> Cc: devicetree-disc...@lists.ozlabs.org
>> Cc: linux-...@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Cc: davinci-linux-open-sou...@linux.davincidsp.com
>
> Acked-by: Laurent Pinchart
>
Thanks for the ack.
> (with two small comment below).
>
>> ---
>> Tested on da850-evm.
>>
[snip]
>
> s/of port/on port/
> s/refer/refer to/
>
OK
>> Documentation/devicetree/bindings/media/video-interfaces.txt.
>> +
>> +Example:
>> +
>> + i2c0@1c22000 {
>> + ...
>> + ...
>> + tvp514x@5c {
>> + compatible = "ti,tvp5146";
>> + reg = <0x5c>;
>> +
>> + port {
>> + tvp514x_1: endpoint {
>> + hsync-active = <1>;
>> + vsync-active = <1>;
>> + pclk-sample = <0>;
>> + };
>> + };
>> + };
>> + ...
>> + };
>> diff --git a/drivers/media/i2c/tvp514x.c b/drivers/media/i2c/tvp514x.c
>> index 7438e01..7ed999b 100644
>> --- a/drivers/media/i2c/tvp514x.c
>> +++ b/drivers/media/i2c/tvp514x.c
>> @@ -39,6 +39,7 @@
>> #include
>> #include
>> #include
>> +#include
>> #include
>> #include
>> #include
>> @@ -1055,6 +1056,42 @@ static struct tvp514x_decoder tvp514x_dev = {
>>
>> };
>>
>> +static struct tvp514x_platform_data *
>> +tvp514x_get_pdata(struct i2c_client *client)
>> +{
>> + struct tvp514x_platform_data *pdata = NULL;
>
> No need to initialize pdata to NULL.
>
OK will fix it in the next version.
Regards,
--Prabhakar Lad
--
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 9/9] media: davinci: vpif_display: Convert to devm_* api
Hi Laurent,
On Wed, May 29, 2013 at 9:08 AM, Laurent Pinchart
wrote:
> On Sunday 26 May 2013 17:30:12 Prabhakar Lad wrote:
>> From: Lad, Prabhakar
>>
>> use devm_request_irq() instead of request_irq(). This ensures
>> more consistent error values and simplifies error paths.
>>
>> Signed-off-by: Lad, Prabhakar
>
> Acked-by: Laurent Pinchart
>
Thanks for the ack.
> with a small comment below.
>
>> ---
>> drivers/media/platform/davinci/vpif_display.c | 35 ++
>> 1 files changed, 9 insertions(+), 26 deletions(-)
>>
>> diff --git a/drivers/media/platform/davinci/vpif_display.c
>> b/drivers/media/platform/davinci/vpif_display.c index 7bcfe7d..e2f080b
>> 100644
>> --- a/drivers/media/platform/davinci/vpif_display.c
>> +++ b/drivers/media/platform/davinci/vpif_display.c
>> @@ -1718,15 +1718,14 @@ static __init int vpif_probe(struct platform_device
>> *pdev)
>>
>> while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, res_idx))) {
>> for (i = res->start; i <= res->end; i++) {
>> - if (request_irq(i, vpif_channel_isr, IRQF_SHARED,
>> - "VPIF_Display", (void *)
>> - (&vpif_obj.dev[res_idx]->channel_id)))
>> {
>> - err = -EBUSY;
>> - for (j = 0; j < i; j++)
>> - free_irq(j, (void *)
>> - (&vpif_obj.dev[res_idx]->channel_id));
>> + err = devm_request_irq(&pdev->dev, i, vpif_channel_isr,
>> + IRQF_SHARED, "VPIF_Display",
>> + (void *)(&vpif_obj.dev[res_idx]->
>> + channel_id));
>> + if (err) {
>> + err = -EINVAL;
>> vpif_err("VPIF IRQ request failed\n");
>> - goto vpif_int_err;
>> + goto vpif_unregister;
>> }
>> }
>> res_idx++;
>> @@ -1744,7 +1743,7 @@ static __init int vpif_probe(struct platform_device
>> *pdev) video_device_release(ch->video_dev);
>> }
>> err = -ENOMEM;
>> - goto vpif_int_err;
>> + goto vpif_unregister;
>> }
>>
>> /* Initialize field of video device */
>> @@ -1878,13 +1877,8 @@ vpif_sd_error:
>> /* Note: does nothing if ch->video_dev == NULL */
>> video_device_release(ch->video_dev);
>> }
>> -vpif_int_err:
>> +vpif_unregister:
>> v4l2_device_unregister(&vpif_obj.v4l2_dev);
>> - for (i = 0; i < res_idx; i++) {
>> - res = platform_get_resource(pdev, IORESOURCE_IRQ, i);
>> - for (j = res->start; j <= res->end; j++)
>> - free_irq(j, (void *)(&vpif_obj.dev[i]->channel_id));
>> - }
>>
>> return err;
>> }
>> @@ -1894,20 +1888,9 @@ vpif_int_err:
>> */
>> static int vpif_remove(struct platform_device *device)
>> {
>> - struct platform_device *pdev;
>> struct channel_obj *ch;
>> - struct resource *res;
>> - int irq_num;
>> int i = 0;
>
> There's no need to initialize i to 0 anymore (same comment for patch 6/9).
>
Ok will fix it in the next version.
Regards,
--Prabhakar Lad
--
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/
linux-next: manual merge of the staging tree with the net-next tree
Hi Greg,
Today's linux-next merge of the staging tree got a conflict in
drivers/staging/silicom/bpctl_mod.c between commit 351638e7deee ("net:
pass info struct via netdevice notifier") from the net-next tree and
commit f84b075178b4 ("Staging: silicom: Fixed error 'do not initialise
statics to 0 or NULL'") from the staging tree.
I fixed it up (see below) and can carry the fix as necessary (no action
is required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
diff --cc drivers/staging/silicom/bpctl_mod.c
index c8ddb99,3082ba9..000
--- a/drivers/staging/silicom/bpctl_mod.c
+++ b/drivers/staging/silicom/bpctl_mod.c
@@@ -133,8 -133,8 +133,8 @@@ static unsigned long str_to_hex(char *p
static int bp_device_event(struct notifier_block *unused,
unsigned long event, void *ptr)
{
- struct net_device *dev = ptr;
+ struct net_device *dev = netdev_notifier_info_to_dev(ptr);
- static bpctl_dev_t *pbpctl_dev = NULL, *pbpctl_dev_m = NULL;
+ static bpctl_dev_t *pbpctl_dev, *pbpctl_dev_m;
int dev_num = 0, ret = 0, ret_d = 0, time_left = 0;
/* printk("BP_PROC_SUPPORT event =%d %s %d\n", event,dev->name,
dev->ifindex ); */
/* return NOTIFY_DONE; */
pgp8pTJQWsApz.pgp
Description: PGP signature
Re: [PATCH v3 4/9] media: davinci: vpif_capture: move the freeing of irq and global variables to remove()
Hi Laurent,
Thanks for the review.
On Wed, May 29, 2013 at 8:02 AM, Laurent Pinchart
wrote:
> Hi Prabhakar,
>
> Thanks for the patch.
>
> On Sunday 26 May 2013 17:30:07 Prabhakar Lad wrote:
>> From: Lad, Prabhakar
>>
>> Ideally the freeing of irq's and the global variables needs to be
>> done in the remove() rather than module_exit(), this patch moves
>> the freeing up of irq's and freeing the memory allocated to channel
>> objects to remove() callback of struct platform_driver.
>>
>> Signed-off-by: Lad, Prabhakar
>> ---
>> drivers/media/platform/davinci/vpif_capture.c | 31 ++
>> 1 files changed, 13 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/media/platform/davinci/vpif_capture.c
>> b/drivers/media/platform/davinci/vpif_capture.c index caaf4fe..f8b7304
>> 100644
>> --- a/drivers/media/platform/davinci/vpif_capture.c
>> +++ b/drivers/media/platform/davinci/vpif_capture.c
>> @@ -2225,17 +2225,29 @@ vpif_int_err:
>> */
>> static int vpif_remove(struct platform_device *device)
>> {
>> - int i;
>> + struct platform_device *pdev;
>> struct channel_obj *ch;
>> + struct resource *res;
>> + int irq_num, i = 0;
>> +
>> + pdev = container_of(vpif_dev, struct platform_device, dev);
>
> As Sergei mentioned, the platform device is already passed to the function as
> an argument.
>
OK
>> + while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, i))) {
>> + for (irq_num = res->start; irq_num <= res->end; irq_num++)
>> + free_irq(irq_num,
>> + (void *)(&vpif_obj.dev[i]->channel_id));
>
> A quick look at board code shows that each IRQ resource contains a single IRQ.
> The second loop could thus be removed. You could also add another patch to
> perform similar cleanup for the probe code.
>
Any way this will code will be removed in the next patch of the same
series due to usage
of devm_* api. I'll do this change only in the probe code.
Regards,
--Prabhakar Lad
--
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] proc: first_tid: fix the potential use-after-free
Oleg Nesterov writes: > proc_task_readdir() verifies that the result of get_proc_task() > is pid_alive() and thus its ->group_leader is fine too. However > this is not necessarily true after rcu_read_unlock(), we need > to recheck this after first_tid() does rcu_read_lock() again. I agree with you but you are missing something critical from your explanation. If a process has been passed through __unhash_process then task->thread_group.next (aka next_thread) returns a pointer to the process that was it's next thread in the thread group. Importantly that pointer is only guaranteed to point to valid memory until the rcu grace period expires. Which means that starting a walk of a thread list with a task that could have been unhashed before the current rcu critical section began is invalid, and can lead to following an invalid pointer. > The race is subtle and unlikely, but still it is possible afaics. > To simplify lets ignore the "likely" case when tid != 0, f_version > can be cleared by proc_task_operations->llseek(). > > Suppose we have a main thread M and its subthread T. Suppose that > f_pos == 3, iow first_tid() should return T. Now suppose that the > following happens between rcu_read_unlock() and rcu_read_lock(): > > 1. T execs and becomes the new leader. This removes M from > ->thread_group but next_thread(M) is still T. > > 2. T creates another thread X which does exec as well, T > goes away. > > 3. X creates another subthread, this increments nr_threads. > > 4. first_tid() does next_thread(M) and returns the already > dead T. > > Note that we need 2. and 3. only because of get_nr_threads() check, > and this check was supposed to be optimization only. An optimization and denial of service attack prevention. It keeps us spinning for nearly unbounded amounts of time in the rcu critical section. But I agree it should not be needed from this part of correctness. > Note: I think that proc_task_readdir/first_tid interaction can be > simplified, but this needs another patch. proc_task_readdir() should > not play with ->group_leader at all. See the next patches. That sounds right. I seem to recall that there was a purpose in keeping the leader pinned but it looks like that purpose is long since gone. > Signed-off-by: Oleg Nesterov > --- > fs/proc/base.c |5 - > 1 files changed, 4 insertions(+), 1 deletions(-) > > diff --git a/fs/proc/base.c b/fs/proc/base.c > index dd51e50..c939c9f 100644 > --- a/fs/proc/base.c > +++ b/fs/proc/base.c > @@ -3186,10 +3186,13 @@ static struct task_struct *first_tid(struct > task_struct *leader, > goto found; > } > > - /* If nr exceeds the number of threads there is nothing todo */ > pos = NULL; > + /* If nr exceeds the number of threads there is nothing todo */ Moving the comment is just noise and makes for confusing reading of your patch. > if (nr && nr >= get_nr_threads(leader)) > goto out; > + /* It could be unhashed before we take rcu lock */ > + if (!pid_alive(leader)) > + goto out; > > /* If we haven't found our starting place yet start >* with the leader and walk nr threads forward. -- 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: EXYNOS: Update defconfig for Arndale and Origen board
On 05/29/2013 04:47 AM, Olof Johansson wrote: > On Tue, May 14, 2013 at 08:37:53AM +0530, Tushar Behera wrote: >> On 05/14/2013 05:36 AM, Kevin Hilman wrote: >>> Tushar Behera writes: >>> It updates following drivers for EXYNOS based DT platform. * S5M8767 driver * MAX8997 driver * MMC SDHCI driver Signed-off-by: Tushar Behera >>> >>> I tested this using v3.10-rc1 on Arndale, but still don't get any >>> support for the wired network. Do you know if this is a Kconfig issue, >>> or a missing driver? >>> >>> I suspect it may be related to the various "unable to find transceiver >>> of type USB2 PHY" messages I'm seeing? >>> >> >> Yes, right. The missing USB-PHY components are one of the issues (they >> were there in linux-next when I last tested). >> >> Also, on Arndale board, we need to reset the USB hub during EHCI >> initialization (a couple of those patches are required, which I am not >> sure if we would be able to upstream). >> >> I am collecting a minimal set of patches that would enable USB and wired >> network on Arndale with 3.10-rc1 kernel. Once done, I will let you know. > > Hi Tushar, > > Got an update on what these patches are yet? > > > -Olof > The patches are at [1]. There are a total of 6 patches on top of v3.10-rc3. 3 of them (a, b, d) are queued for 3.10-rc4 and another patch (c) is just a defconfig hack to get Arndale booting. Remaining 2 patches (e, f) are required to reset the hub during EHCI initialization. a. ARM: exynos: defconfig update b. ARM: EXYNOS: Update defconfig for Arndale and Origen board c. [TEMP] ARM: EXYNOS: Set low-level UART port to 2 d. ARM: dts: Enabling samsung-usb2phy driver for exynos5250 e. usb: ehci-s5p: add the HSIC port initialization f. ARM: dts: Add USB gpio entries for Arndale board I am not sure whether such kind of board-specific patches (e, f) are appreciated in the drivers. But that is all we need to get USB and Ethernet to work on v3.10-rc3 kernel. [1] git://git.linaro.org/landing-teams/working/samsung/kernel.git (upstream/arndale-usb) -- Tushar Behera -- 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 for thinkpad-acpi.c
Hi, Bjorn
Thank your advice .
I will modify my code, then try to submit again.
Bruce.Ma
May 29,2013
On 05/28/2013 06:28 PM, Bjørn Mork wrote:
> Bruce writes:
>
>> +struct blacklist lenovo_blacklist[] = {
>> + {
>> +.model_s = "Lenovo LM490s",
>> +.nummodel_s = "814YG01",
>> + },
>
> The driver already has a list of LED support per model in the
>
> static const struct tpacpi_quirk led_useful_qtable[] __initconst = {}
>
> array. Why do you duplicate this with lots of new model checking code
> instead of just using the code that's already there?
>
>> static void led_exit(void)
>> {
>> +if (no_led == 1 ) {
>
> The driver already has provisions for signalling that LEDs are
> unsupported through the 'led_supported' variable. Why do you add
> another variable, and duplicate testing in every access function?
>
> But I don't think this part is needed at all, as long as you set up the
> proper LED map in led_useful_qtable.
>
>
>
> Bjørn
--
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] media: i2c: mt9p031: add OF support
Hi Laurent, On Wed, May 29, 2013 at 9:01 AM, Laurent Pinchart wrote: > Hi Prabhakar, > > Thanks for the patch. > > On Sunday 26 May 2013 18:38:54 Prabhakar Lad wrote: >> From: Lad, Prabhakar >> >> add OF support for the mt9p031 sensor driver. >> Alongside this patch sorts the header inclusion alphabetically. >> >> Signed-off-by: Lad, Prabhakar >> Cc: Hans Verkuil >> Cc: Laurent Pinchart >> Cc: Mauro Carvalho Chehab >> Cc: Guennadi Liakhovetski >> Cc: Sylwester Nawrocki >> Cc: Sakari Ailus >> Cc: Grant Likely >> Cc: Sascha Hauer >> Cc: Rob Herring >> Cc: Rob Landley >> Cc: Arnd Bergmann >> Cc: devicetree-disc...@lists.ozlabs.org >> Cc: davinci-linux-open-sou...@linux.davincidsp.com >> Cc: linux-...@vger.kernel.org >> Cc: linux-kernel@vger.kernel.org > > Acked-by: Laurent Pinchart > > And added to my tree with three small changes (please see below). > Thanks for applying it, with the changes :) Regards, --Prabhakar lad -- 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 v1 0/9] adding dual instance and usb-phy support for am335x platform
Felipe
> Subject: Re: [PATCH v1 0/9] adding dual instance and usb-phy support for
> am335x platform
> Hi,
>On Thu, May 23, 2013 at 11:31:19AM +0530, Ravi Babu wrote:
>> This patch set series
>> - adds dual musb instances support for am335x platform
>> - adds phy-dsps-usb driver based on TI's gs70 driver
>> - adds DT bindings for am33xx usb-phy
>> - removed references to usb-nop-xceiv from musb
>as Sergei pointed out, this would break some DaVinci/DA8xx platforms, so I'm
>dropping from it from my queue.
As I understand, already all musb glue platform drivers(dsps/davinci/da8xx) are
changed to new usb_get_phy() API set.
Currently the mainline code snippet as shown.
dsps/davinci/da8xx/xxx_musb_init() {
...
usb_nop_xceiv_register()
..
musb->xceiv = usb_get_phy(USB_PHY_TYPE_USB2);
if (IS_ERR_OR_NULL(musb->xceiv)) {
ret = -EPROBE_DEFER;
goto fail;
}
..
}
Because of this all glue xxx_musb_init() will fail to get the phy without the
phy-bindings for each controller.
Without this patch series am335x musb will fail to get usb_phy(). Similarly phy
support to be added for all davinci/da8xx
platform also. The usb_nop_xciev_xx() is dummy unused API here and hence
removed from all glue in this patch series.
1) dsps platforms (am335x/dm81xx) series uses TI gs70 based phy
This patch adds support for ths dsps phy driver at
drivers/usb/phy/usb-dsps-phy.c
2) omapl13x/da8xx series of soc uses different phy
Separate phy driver need to be added at drivers/usb/phy/usb-da8xx-phy.c
3) similarly all davinci series of soc uses separate TI-phy
Separate phy driver need to added at drivers/usb/phy/usb-davinci-phy.c
The bindings of the respective usb-phy and controller need to done in DT or
non-DT way.
I can add usb-phy support for davinci/da8xx platform in similar way.
---
Ravi B
--
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/
[RFC PATCH] cpufreq: stats: Add 'load_table' sysfs file to show accumulated data of CPU
This patch add new sysfs file to show previous accumulated data of CPU load as following path. This sysfs file is used to judge the correct system state or determine suitable system resource on user-space. - /sys/devices/system/cpu/cpu0/cpufreq/stats/load_table This sysfs file include following data: - Measurement point of time - CPU frequency - Per-CPU load Signed-off-by: Chanwoo Choi Signed-off-by: Myungjoo Ham Signed-off-by: Kyungmin Park --- Additionally, I explain an example using 'load_table' sysfs entry. Exynos4412 series has Quad-core and all cores share the power-line. I cann't set diffent voltage/frequency to each CPU. To reduce power- consumption, I certainly have to turn on/off CPU online state according to CPU load on runtime. As a result, I peridically need to monitor current cpu state to determine a proper amount of system resource(necessary number of online cpu) and to delete wasted power. So, I need 'load_table' sysfs file to monitor current cpu state. I add a table which show power consumption of target based on Exynos4412 SoC. This table indicate the difference power-consumption according to a number of online core and with same number of running task. [Environment of power estimation] - cpufreq governor used performance mode to estimate power-consumption on each frequency step. - Use infinite-loop test program which execute while statement infinitely. - Always measure the power consumption under same temperature during 1 minutes. - Unit is mA. A number of Online core | Core 1| Core 2| Core 3 | Core 4 A number of nr_running | 0 1 | 0 1 2 | 0 1 2 3 | 0 1 2 3 4 CPU Frequency | 800 MHz | 293 330 | 295 338 379 | 300 339 386 433 | 303 341 390 412 482 1000 MHz | 312 371 | 316 377 435 | 318 383 454 522 | 322 391 462 526 596 1200 MHz | 323 404 | 328 418 504 | 336 423 521 615 | 343 433 499 639 748 1600 MHz | 380 525 | 388 556 771 | 399 575 771 1011| 412 597 822 11721684 For example, The case A/B/C have the same condition except for a number of online core. - case A: Online core is 2, 1000MHz and nr_running is 1 : 377mA - case B: Online core is 3, 1000MHz and nr_running is 1 : 383mA - case C: Online core is 4, 1000Mz and nr_running is 1 : 391mA If system has only one running task, cpu hotplug policy, by monitoring cpu state through 'load_table' sysfs file on user-space, will determine 'case A' state for reducing power-consumption. Show the result of reading 'load_table sysfs file as following: - cpufreq governor is ondemand_org governor. $ cat /sys/devices/system/cpu/cpu0/cpufreq/stats/load_table Time Frequency cpu0 cpu1 cpu2 cpu3 1300500043122 160 3260 26 130060007908080 63 102 45 130070006528880 5191 42 130080022874780 5191 43 130090018299780 78 113 47 130100010616380 96 266 48 1301100056247 160 4571 27 1301200071373 100 5591 37 130130009608280 54 100 45 130140013283280 70 112 46 130150008229080 61 111 43 130160023641580 6192 43 130170007149880 59 102 43 130180015929080 5591 42 130190007633280 66 102 43 130200010216580 4790 43 130210008662380 75 112 50 130220010108280 66 104 46 130230010887380 53 101 44 130240037337360 63 121 54 Please let me know some opinion about this patch. Best regards and Thanks, Chanwoo Choi --- drivers/cpufreq/cpufreq.c | 4 +++ drivers/cpufreq/cpufreq_governor.c | 21 ++-- drivers/cpufreq/cpufreq_stats.c| 70 ++ include/linux/cpufreq.h| 6 4 files changed, 99 insertions(+), 2 deletions(-) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index 2d53f47..cbaaff0 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -292,6 +292,10 @@ void __cpufreq_notify_transition(struct cpufreq_policy *policy, if (likely(policy) && likely(policy->cpu == freqs->cpu)) policy->cur = freqs
Re: [PATCH v3 9/9] media: davinci: vpif_display: Convert to devm_* api
On Sunday 26 May 2013 17:30:12 Prabhakar Lad wrote:
> From: Lad, Prabhakar
>
> use devm_request_irq() instead of request_irq(). This ensures
> more consistent error values and simplifies error paths.
>
> Signed-off-by: Lad, Prabhakar
Acked-by: Laurent Pinchart
with a small comment below.
> ---
> drivers/media/platform/davinci/vpif_display.c | 35 ++
> 1 files changed, 9 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/media/platform/davinci/vpif_display.c
> b/drivers/media/platform/davinci/vpif_display.c index 7bcfe7d..e2f080b
> 100644
> --- a/drivers/media/platform/davinci/vpif_display.c
> +++ b/drivers/media/platform/davinci/vpif_display.c
> @@ -1718,15 +1718,14 @@ static __init int vpif_probe(struct platform_device
> *pdev)
>
> while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, res_idx))) {
> for (i = res->start; i <= res->end; i++) {
> - if (request_irq(i, vpif_channel_isr, IRQF_SHARED,
> - "VPIF_Display", (void *)
> - (&vpif_obj.dev[res_idx]->channel_id))) {
> - err = -EBUSY;
> - for (j = 0; j < i; j++)
> - free_irq(j, (void *)
> - (&vpif_obj.dev[res_idx]->channel_id));
> + err = devm_request_irq(&pdev->dev, i, vpif_channel_isr,
> + IRQF_SHARED, "VPIF_Display",
> + (void *)(&vpif_obj.dev[res_idx]->
> + channel_id));
> + if (err) {
> + err = -EINVAL;
> vpif_err("VPIF IRQ request failed\n");
> - goto vpif_int_err;
> + goto vpif_unregister;
> }
> }
> res_idx++;
> @@ -1744,7 +1743,7 @@ static __init int vpif_probe(struct platform_device
> *pdev) video_device_release(ch->video_dev);
> }
> err = -ENOMEM;
> - goto vpif_int_err;
> + goto vpif_unregister;
> }
>
> /* Initialize field of video device */
> @@ -1878,13 +1877,8 @@ vpif_sd_error:
> /* Note: does nothing if ch->video_dev == NULL */
> video_device_release(ch->video_dev);
> }
> -vpif_int_err:
> +vpif_unregister:
> v4l2_device_unregister(&vpif_obj.v4l2_dev);
> - for (i = 0; i < res_idx; i++) {
> - res = platform_get_resource(pdev, IORESOURCE_IRQ, i);
> - for (j = res->start; j <= res->end; j++)
> - free_irq(j, (void *)(&vpif_obj.dev[i]->channel_id));
> - }
>
> return err;
> }
> @@ -1894,20 +1888,9 @@ vpif_int_err:
> */
> static int vpif_remove(struct platform_device *device)
> {
> - struct platform_device *pdev;
> struct channel_obj *ch;
> - struct resource *res;
> - int irq_num;
> int i = 0;
There's no need to initialize i to 0 anymore (same comment for patch 6/9).
> - pdev = container_of(vpif_dev, struct platform_device, dev);
> - while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, i))) {
> - for (irq_num = res->start; irq_num <= res->end; irq_num++)
> - free_irq(irq_num,
> - (void *)(&vpif_obj.dev[i]->channel_id));
> - i++;
> - }
> -
> v4l2_device_unregister(&vpif_obj.v4l2_dev);
>
> kfree(vpif_obj.sd);
--
Regards,
Laurent Pinchart
--
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 6/9] media: davinci: vpif_capture: Convert to devm_* api
On Sunday 26 May 2013 17:30:09 Prabhakar Lad wrote:
> From: Lad, Prabhakar
>
> use devm_request_irq() instead of request_irq(). This ensures
> more consistent error values and simplifies error paths.
>
> Signed-off-by: Lad, Prabhakar
Acked-by: Laurent Pinchart
> ---
> drivers/media/platform/davinci/vpif_capture.c | 38 --
> 1 files changed, 12 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/media/platform/davinci/vpif_capture.c
> b/drivers/media/platform/davinci/vpif_capture.c index 38c1fba..5e1e5f6
> 100644
> --- a/drivers/media/platform/davinci/vpif_capture.c
> +++ b/drivers/media/platform/davinci/vpif_capture.c
> @@ -2082,14 +2082,14 @@ static __init int vpif_probe(struct platform_device
> *pdev)
>
> while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, res_idx))) {
> for (i = res->start; i <= res->end; i++) {
> - if (request_irq(i, vpif_channel_isr, IRQF_SHARED,
> - "VPIF_Capture", (void *)
> - (&vpif_obj.dev[res_idx]->channel_id))) {
> - err = -EBUSY;
> - for (j = 0; j < i; j++)
> - free_irq(j, (void *)
> - (&vpif_obj.dev[res_idx]->channel_id));
> - goto vpif_int_err;
> + err = devm_request_irq(&pdev->dev, i, vpif_channel_isr,
> + IRQF_SHARED, "VPIF_Capture",
> + (void *)(&vpif_obj.dev[res_idx]->
> + channel_id));
> + if (err) {
> + err = -EINVAL;
> + goto vpif_unregister;
> +
> }
> }
> res_idx++;
> @@ -2106,7 +2106,7 @@ static __init int vpif_probe(struct platform_device
> *pdev) video_device_release(ch->video_dev);
> }
> err = -ENOMEM;
> - goto vpif_int_err;
> + goto vpif_unregister;
> }
>
> /* Initialize field of video device */
> @@ -2207,13 +2207,9 @@ vpif_sd_error:
> /* Note: does nothing if ch->video_dev == NULL */
> video_device_release(ch->video_dev);
> }
> -vpif_int_err:
> +vpif_unregister:
> v4l2_device_unregister(&vpif_obj.v4l2_dev);
> - for (i = 0; i < res_idx; i++) {
> - res = platform_get_resource(pdev, IORESOURCE_IRQ, i);
> - for (j = res->start; j <= res->end; j++)
> - free_irq(j, (void *)(&vpif_obj.dev[i]->channel_id));
> - }
> +
> return err;
> }
>
> @@ -2225,18 +2221,8 @@ vpif_int_err:
> */
> static int vpif_remove(struct platform_device *device)
> {
> - struct platform_device *pdev;
> struct channel_obj *ch;
> - struct resource *res;
> - int irq_num, i = 0;
> -
> - pdev = container_of(vpif_dev, struct platform_device, dev);
> - while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, i))) {
> - for (irq_num = res->start; irq_num <= res->end; irq_num++)
> - free_irq(irq_num,
> - (void *)(&vpif_obj.dev[i]->channel_id));
> - i++;
> - }
> + int i;
>
> v4l2_device_unregister(&vpif_obj.v4l2_dev);
--
Regards,
Laurent Pinchart
--
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/
linux-next: build failure after merge of the xen-arm tree
Hi Stefano,
After merging the xen-arm tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
kernel/sched/cputime.c:8:26: fatal error: asm/paravirt.h: No such file or
directory
#include
^
Caused by commit d31d069a9f68 ("kernel: missing include in cputime.c").
Only three architectures have that file (x86, arm and ia64).
I have used the xen-arm tree from next-20130528 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpyQK9EOYNIp.pgp
Description: PGP signature
Re: [PATCH v3 8/9] media: davinci: vpif_display: use module_platform_driver()
On Sunday 26 May 2013 17:30:11 Prabhakar Lad wrote:
> From: Lad, Prabhakar
>
> This patch uses module_platform_driver() to simplify the code.
>
> Signed-off-by: Lad, Prabhakar
Acked-by: Laurent Pinchart
> ---
> drivers/media/platform/davinci/vpif_display.c | 18 +-
> 1 files changed, 1 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/media/platform/davinci/vpif_display.c
> b/drivers/media/platform/davinci/vpif_display.c index 9c308e7..7bcfe7d
> 100644
> --- a/drivers/media/platform/davinci/vpif_display.c
> +++ b/drivers/media/platform/davinci/vpif_display.c
> @@ -2005,20 +2005,4 @@ static __refdata struct platform_driver vpif_driver =
> { .remove = vpif_remove,
> };
>
> -static __init int vpif_init(void)
> -{
> - return platform_driver_register(&vpif_driver);
> -}
> -
> -/*
> - * vpif_cleanup: This function un-registers device and driver to the
> kernel, - * frees requested irq handler and de-allocates memory allocated
> for channel - * objects.
> - */
> -static void vpif_cleanup(void)
> -{
> - platform_driver_unregister(&vpif_driver);
> -}
> -
> -module_init(vpif_init);
> -module_exit(vpif_cleanup);
> +module_platform_driver(vpif_driver);
--
Regards,
Laurent Pinchart
--
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 5/9] media: davinci: vpif_capture: use module_platform_driver()
On Sunday 26 May 2013 17:30:08 Prabhakar Lad wrote:
> From: Lad, Prabhakar
>
> This patch uses module_platform_driver() to simplify the code.
>
> Signed-off-by: Lad, Prabhakar
Acked-by: Laurent Pinchart
> ---
> drivers/media/platform/davinci/vpif_capture.c | 28 +-
> 1 files changed, 1 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/media/platform/davinci/vpif_capture.c
> b/drivers/media/platform/davinci/vpif_capture.c index f8b7304..38c1fba
> 100644
> --- a/drivers/media/platform/davinci/vpif_capture.c
> +++ b/drivers/media/platform/davinci/vpif_capture.c
> @@ -2338,30 +2338,4 @@ static __refdata struct platform_driver vpif_driver =
> { .remove = vpif_remove,
> };
>
> -/**
> - * vpif_init: initialize the vpif driver
> - *
> - * This function registers device and driver to the kernel, requests irq
> - * handler and allocates memory
> - * for channel objects
> - */
> -static __init int vpif_init(void)
> -{
> - return platform_driver_register(&vpif_driver);
> -}
> -
> -/**
> - * vpif_cleanup : This function clean up the vpif capture resources
> - *
> - * This will un-registers device and driver to the kernel, frees
> - * requested irq handler and de-allocates memory allocated for channel
> - * objects.
> - */
> -static void vpif_cleanup(void)
> -{
> - platform_driver_unregister(&vpif_driver);
> -}
> -
> -/* Function for module initialization and cleanup */
> -module_init(vpif_init);
> -module_exit(vpif_cleanup);
> +module_platform_driver(vpif_driver);
--
Regards,
Laurent Pinchart
--
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] media: i2c: mt9p031: add OF support
Hi Prabhakar,
Thanks for the patch.
On Sunday 26 May 2013 18:38:54 Prabhakar Lad wrote:
> From: Lad, Prabhakar
>
> add OF support for the mt9p031 sensor driver.
> Alongside this patch sorts the header inclusion alphabetically.
>
> Signed-off-by: Lad, Prabhakar
> Cc: Hans Verkuil
> Cc: Laurent Pinchart
> Cc: Mauro Carvalho Chehab
> Cc: Guennadi Liakhovetski
> Cc: Sylwester Nawrocki
> Cc: Sakari Ailus
> Cc: Grant Likely
> Cc: Sascha Hauer
> Cc: Rob Herring
> Cc: Rob Landley
> Cc: Arnd Bergmann
> Cc: devicetree-disc...@lists.ozlabs.org
> Cc: davinci-linux-open-sou...@linux.davincidsp.com
> Cc: linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
Acked-by: Laurent Pinchart
And added to my tree with three small changes (please see below).
> ---
> Changes for NON RFC v1:
> 1: added missing call for of_node_put().
>
> Changes for RFC v4 (https://patchwork.kernel.org/patch/2556251/):
> 1: Renamed "gpio-reset" property to "reset-gpios".
> 2: Dropped assigning the driver data from the of node.
>
> Changes for RFC v3(https://patchwork.kernel.org/patch/2515921/):
> 1: Dropped check if gpio-reset is valid.
> 2: Fixed some code nits.
> 3: Included a reference to the V4L2 DT bindings documentation.
>
> Changes for RFC v2 (https://patchwork.kernel.org/patch/2510201/):
> 1: Used '-' instead of '_' for device properties.
> 2: Specified gpio reset pin as phandle in device node.
> 3: Handle platform data properly even if kernel is compiled with
> devicetree support.
> 4: Used dev_* for messages in drivers instead of pr_*.
> 5: Changed compatible property to "aptina,mt9p031" and "aptina,mt9p031m".
> 6: Sorted the header inclusion alphabetically and fixed some minor code
> nits.
>
> RFC v1: https://patchwork.kernel.org/patch/2498791/
>
> .../devicetree/bindings/media/i2c/mt9p031.txt | 40
> ++ drivers/media/i2c/mt9p031.c|
> 43 +++- 2 files changed, 81 insertions(+), 2 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/mt9p031.txt
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/mt9p031.txt
> b/Documentation/devicetree/bindings/media/i2c/mt9p031.txt new file mode
> 100644
> index 000..59d613c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/mt9p031.txt
> @@ -0,0 +1,40 @@
> +* Aptina 1/2.5-Inch 5Mp CMOS Digital Image Sensor
> +
> +The Aptina MT9P031 is a 1/2.5-inch CMOS active pixel digital image sensor
> with +an active array size of 2592H x 1944V. It is programmable through a
> simple +two-wire serial interface.
> +
> +Required Properties :
> +- compatible : value should be either one among the following
> + (a) "aptina,mt9p031" for mt9p031 sensor
> + (b) "aptina,mt9p031m" for mt9p031m sensor
> +
> +- input-clock-frequency : Input clock frequency.
> +
> +- pixel-clock-frequency : Pixel clock frequency.
> +
> +Optional Properties :
> +- reset-gpios: Chip reset GPIO
There's usually no space before a colon in English.
> +For further reading of port node refer
> Documentation/devicetree/bindings/media/video-interfaces.txt.
> +
> +Example:
> +
> + i2c0@1c22000 {
> + ...
> + ...
> + mt9p031@5d {
> + compatible = "aptina,mt9p031";
> + reg = <0x5d>;
> + reset-gpios = <&gpio3 30 0>;
> +
> + port {
> + mt9p031_1: endpoint {
> + input-clock-frequency = <600>;
> + pixel-clock-frequency = <9600>;
> + };
> + };
> + };
> + ...
> + };
> diff --git a/drivers/media/i2c/mt9p031.c b/drivers/media/i2c/mt9p031.c
> index bf49899..bb1f993 100644
> --- a/drivers/media/i2c/mt9p031.c
> +++ b/drivers/media/i2c/mt9p031.c
> @@ -16,9 +16,10 @@
> #include
> #include
> #include
> -#include
> #include
> #include
> +#include
> +#include
> #include
> #include
> #include
> @@ -28,6 +29,7 @@
> #include
> #include
> #include
> +#include
> #include
>
> #include "aptina-pll.h"
> @@ -928,10 +930,37 @@ static const struct v4l2_subdev_internal_ops
> mt9p031_subdev_internal_ops = { * Driver initialization and probing
> */
>
> +static struct mt9p031_platform_data *
> +mt9p031_get_pdata(struct i2c_client *client)
> +{
> + struct mt9p031_platform_data *pdata = NULL;
No need to initialize pdata to NULL here.
> + struct device_node *np;
> +
> + if (!IS_ENABLED(CONFIG_OF) || !client->dev.of_node)
> + return client->dev.platform_data;
> +
> + np = v4l2_of_get_next_endpoint(client->dev.of_node, NULL);
> + if (!np)
> + return NULL;
> +
> + pdata = devm_kzalloc(&client->dev, sizeof(struct mt9p031_platform_data),
> + GFP_KERNEL);
The preferred way to use sizeof in the kernel is sizeof(*v
Re: [BUG] with rcu nocb, don't call wake up holding rnp->lock (was: rcu_read_lock() used illegally while idle!)
On Tue, May 28, 2013 at 05:32:53PM -0400, Steven Rostedt wrote:
> Paul, this looks to be a nocb rcu bug.
Excellent work tracing this down! I have queued your fix, and if it
passes testing, I will push for 3.10.
Thanx, Paul
> On Tue, 2013-05-28 at 16:13 -0400, Dave Jones wrote:
>
> > [12572.705832] ==
> > [12572.750317] [ INFO: possible circular locking dependency detected ]
> > [12572.796978] 3.10.0-rc3+ #39 Not tainted
> > [12572.833381] ---
> > [12572.862233] trinity-child17/31341 is trying to acquire lock:
> > [12572.870390] (rcu_node_0){..-.-.}, at: []
> > rcu_read_unlock_special+0x9f/0x4c0
> > [12572.878859]
> > but task is already holding lock:
> > [12572.894894] (&ctx->lock){-.-...}, at: []
> > perf_lock_task_context+0x7d/0x2d0
> > [12572.903381]
> > which lock already depends on the new lock.
> >
> > [12572.927541]
> > the existing dependency chain (in reverse order) is:
> > [12572.943736]
> > -> #4 (&ctx->lock){-.-...}:
> > [12572.960032][] lock_acquire+0x91/0x1f0
> > [12572.968337][] _raw_spin_lock+0x40/0x80
> > [12572.976633][]
> > __perf_event_task_sched_out+0x2e7/0x5e0
> > [12572.984969][]
> > perf_event_task_sched_out+0x93/0xa0
> > [12572.993326][] __schedule+0x2cf/0x9c0
> > [12573.001652][] schedule_user+0x2e/0x70
> > [12573.009998][] retint_careful+0x12/0x2e
> > [12573.018321]
> > -> #3 (&rq->lock){-.-.-.}:
> > [12573.034628][] lock_acquire+0x91/0x1f0
> > [12573.042930][] _raw_spin_lock+0x40/0x80
> > [12573.051248][] wake_up_new_task+0xb7/0x260
> > [12573.059579][] do_fork+0x105/0x470
> > [12573.067880][] kernel_thread+0x26/0x30
> > [12573.076202][] rest_init+0x23/0x140
> > [12573.084508][] start_kernel+0x3f1/0x3fe
> > [12573.092852][]
> > x86_64_start_reservations+0x2a/0x2c
> > [12573.101233][] x86_64_start_kernel+0xcc/0xcf
> > [12573.109528]
> > -> #2 (&p->pi_lock){-.-.-.}:
> > [12573.125675][] lock_acquire+0x91/0x1f0
> > [12573.133829][] _raw_spin_lock_irqsave+0x4b/0x90
> > [12573.141964][] try_to_wake_up+0x31/0x320
> > [12573.150065][] default_wake_function+0x12/0x20
> > [12573.158151][]
> > autoremove_wake_function+0x18/0x40
> > [12573.166195][] __wake_up_common+0x58/0x90
> > [12573.174215][] __wake_up+0x39/0x50
> > [12573.182146][]
> > rcu_start_gp_advanced.isra.11+0x4a/0x50
> > [12573.190119][] rcu_start_future_gp+0x1c9/0x1f0
> > [12573.198023][] rcu_nocb_kthread+0x114/0x930
> > [12573.205860][] kthread+0xed/0x100
> > [12573.213656][] ret_from_fork+0x7c/0xb0
> > [12573.221379]
> > -> #1 (&rsp->gp_wq){..-.-.}:
> > [12573.236329][] lock_acquire+0x91/0x1f0
> > [12573.243783][] _raw_spin_lock_irqsave+0x4b/0x90
> > [12573.251178][] __wake_up+0x23/0x50
> > [12573.258505][]
> > rcu_start_gp_advanced.isra.11+0x4a/0x50
> > [12573.265891][] rcu_start_future_gp+0x1c9/0x1f0
> > [12573.273248][] rcu_nocb_kthread+0x114/0x930
> > [12573.280564][] kthread+0xed/0x100
> > [12573.287807][] ret_from_fork+0x7c/0xb0
>
> Notice the above call chain.
>
> rcu_start_future_gp() is called with the rnp->lock held. Then it calls
> rcu_start_gp_advance, which does a wakeup.
>
> You can't do wakeups while holding the rnp->lock, as that would mean
> that you could not do a rcu_read_unlock() while holding the rq lock, or
> any lock that was taken while holding the rq lock. This is because...
> (See below).
>
>
> > [12573.295067]
> > -> #0 (rcu_node_0){..-.-.}:
> > [12573.309293][] __lock_acquire+0x1786/0x1af0
> > [12573.316568][] lock_acquire+0x91/0x1f0
> > [12573.323825][] _raw_spin_lock+0x40/0x80
> > [12573.331081][]
> > rcu_read_unlock_special+0x9f/0x4c0
> > [12573.338377][] __rcu_read_unlock+0x96/0xa0
> > [12573.345648][]
> > perf_lock_task_context+0x143/0x2d0
> > [12573.352942][] find_get_context+0x4e/0x1f0
> > [12573.360211][] SYSC_perf_event_open+0x514/0xbd0
> > [12573.367514][] SyS_perf_event_open+0x9/0x10
> > [12573.374816][] tracesys+0xdd/0xe2
>
> Notice the above trace.
>
> perf took its own ctx->lock, which can be taken while holding the rq
> lock. While holding this lock, it did a rcu_read_unlock(). The
> perf_lock_task_context() basically looks like:
>
> rcu_read_lock();
> raw_spin_lock(ctx->lock);
> rcu_read_unlock();
>
> Now, what looks to have happened, is that we scheduled after taking that
> first rcu_read_lock() but before taking the spin lock. When we scheduled
> back in and took the ctx->lock, the following rcu_read_unlock()
> triggered the "special" code.
>
> The rcu_read_unlock_special() takes the rnp->lock, which gives us a
> possible dea
[PATCH] ARM: mmp: bring up pxa988 with device tree support
bring up pxa988 with device tree support.
Change-Id: I6fc869b7d5ff8dc6e4eb0042a89429200f7a9fb1
Signed-off-by: Neil Zhang
Signed-off-by: Chao Xie
---
arch/arm/boot/dts/pxa988-dkb.dts | 36 ++
arch/arm/boot/dts/pxa988.dtsi | 189 +
arch/arm/mach-mmp/Kconfig | 27
arch/arm/mach-mmp/Makefile|2 +
arch/arm/mach-mmp/common.c| 11 ++-
arch/arm/mach-mmp/common.h|2 +
arch/arm/mach-mmp/headsmp.S | 104
arch/arm/mach-mmp/include/mach/addr-map.h |6 +
arch/arm/mach-mmp/mmpx-dt.c | 74 +++
arch/arm/mach-mmp/platsmp.c | 163 +
arch/arm/mach-mmp/reset.c | 66 ++
arch/arm/mach-mmp/reset.h | 29 +
drivers/clk/mmp/Makefile |1 +
13 files changed, 709 insertions(+), 1 deletions(-)
create mode 100644 arch/arm/boot/dts/pxa988-dkb.dts
create mode 100644 arch/arm/boot/dts/pxa988.dtsi
create mode 100644 arch/arm/mach-mmp/headsmp.S
create mode 100644 arch/arm/mach-mmp/mmpx-dt.c
create mode 100644 arch/arm/mach-mmp/platsmp.c
create mode 100644 arch/arm/mach-mmp/reset.c
create mode 100644 arch/arm/mach-mmp/reset.h
diff --git a/arch/arm/boot/dts/pxa988-dkb.dts b/arch/arm/boot/dts/pxa988-dkb.dts
new file mode 100644
index 000..2cee3ed
--- /dev/null
+++ b/arch/arm/boot/dts/pxa988-dkb.dts
@@ -0,0 +1,36 @@
+/*
+ * Copyright (C) 2012 Marvell Technology Group Ltd.
+ * Author: Haojian Zhuang
+ *
+ * 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
+ * publishhed by the Free Software Foundation.
+ */
+
+/dts-v1/;
+/include/ "pxa988.dtsi"
+
+/ {
+ model = "Marvell PXA988 DKB Development Board";
+ compatible = "mrvl,pxa988-dkb", "mrvl,pxa988";
+
+ chosen {
+ bootargs = "console=ttyS0,115200 root=/dev/nfs
nfsroot=192.168.1.100:/nfsroot/
ip=192.168.1.101:192.168.1.100::255.255.255.0::eth0:on";
+ };
+
+ memory {
+ reg = <0x 0x1000>;
+ };
+
+ soc {
+ apb@d400 {
+ uart1: uart@d4017000 {
+ status = "okay";
+ };
+
+ rtc: rtc@d401 {
+ status = "okay";
+ };
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/pxa988.dtsi b/arch/arm/boot/dts/pxa988.dtsi
new file mode 100644
index 000..567d33d
--- /dev/null
+++ b/arch/arm/boot/dts/pxa988.dtsi
@@ -0,0 +1,189 @@
+/*
+ * Copyright (C) 2013 Marvell Technology Group Ltd.
+ * Author: Chao Xie
+ *
+ * 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
+ * publishhed by the Free Software Foundation.
+ */
+
+/include/ "skeleton.dtsi"
+
+/ {
+ interrupt-parent = <&gic>;
+
+ aliases {
+ serial0 = &uart1;
+ serial1 = &uart2;
+ serial2 = &uart3;
+ i2c0 = &twsi1;
+ i2c1 = &twsi2;
+ };
+
+ cpus {
+ cpu@0 {
+ compatible = "arm,cortex-a9";
+ next-level-cache = <&L2>;
+ };
+ cpu@1 {
+ compatible = "arm,cortex-a9";
+ next-level-cache = <&L2>;
+ };
+ };
+
+ gic: interrupt-controller@d1dfe100 {
+ compatible = "arm,cortex-a9-gic";
+ interrupt-controller;
+ #interrupt-cells = <3>;
+ reg = <0xd1dff000 0x1000>,
+ <0xd1dfe100 0x0100>;
+ };
+
+ L2: l2-cache-controller@d1dfb000 {
+ compatible = "arm,pl310-cache";
+ reg = <0xd1dfb000 0x1000>;
+ arm,data-latency = <2 1 1>;
+ arm,tag-latency = <2 1 1>;
+ arm,pwr-dynamic-clk-gating;
+ arm,pwr-standby-mode;
+ cache-unified;
+ cache-level = <2>;
+ };
+
+ local-timer@d1dfe600 {
+ compatible = "arm,cortex-a9-twd-timer";
+ reg = <0xd1dfe600 0x20>;
+ interrupts = <1 13 0x304>;
+ };
+
+ soc {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "simple-bus";
+ interrupt-parent = <&gic>;
+ ranges;
+
+ axi@d420 { /* AXI */
+ compatible = "mrvl,axi-bus", "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0xd420 0x0020>;
+ ranges;
+
+ intc: wakeupgen@d4282000 {
+
[PATCH] bring up pxa988 with DT
This patch is supposed to bring up pxa988 SMP. will change to use CLOCKSOURCE later. Neil Zhang (1): ARM: mmp: bring up pxa988 with device tree support arch/arm/boot/dts/pxa988-dkb.dts | 36 ++ arch/arm/boot/dts/pxa988.dtsi | 189 + arch/arm/mach-mmp/Kconfig | 27 arch/arm/mach-mmp/Makefile|2 + arch/arm/mach-mmp/common.c| 11 ++- arch/arm/mach-mmp/common.h|2 + arch/arm/mach-mmp/headsmp.S | 104 arch/arm/mach-mmp/include/mach/addr-map.h |6 + arch/arm/mach-mmp/mmpx-dt.c | 74 +++ arch/arm/mach-mmp/platsmp.c | 163 + arch/arm/mach-mmp/reset.c | 66 ++ arch/arm/mach-mmp/reset.h | 29 + drivers/clk/mmp/Makefile |1 + 13 files changed, 709 insertions(+), 1 deletions(-) create mode 100644 arch/arm/boot/dts/pxa988-dkb.dts create mode 100644 arch/arm/boot/dts/pxa988.dtsi create mode 100644 arch/arm/mach-mmp/headsmp.S create mode 100644 arch/arm/mach-mmp/mmpx-dt.c create mode 100644 arch/arm/mach-mmp/platsmp.c create mode 100644 arch/arm/mach-mmp/reset.c create mode 100644 arch/arm/mach-mmp/reset.h -- 1.7.4.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 v5] clocksource: add Freescale Vybrid pit timer support
On Tue, May 28, 2013 at 05:21:39PM +0800, Jingchang Lu wrote: > Add Freescale Vybrid Family period interrupt timer support. > > Signed-off-by: Jingchang Lu Acked-by: Shawn Guo -- 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 v7 10/11] KVM: MMU: collapse TLB flushes when zap all pages
On 05/28/2013 11:19 PM, Xiao Guangrong wrote: > On 05/28/2013 08:36 AM, Marcelo Tosatti wrote: >> On Thu, May 23, 2013 at 03:55:59AM +0800, Xiao Guangrong wrote: >>> kvm_zap_obsolete_pages uses lock-break technique to zap pages, >>> it will flush tlb every time when it does lock-break >>> >>> We can reload mmu on all vcpus after updating the generation >>> number so that the obsolete pages are not used on any vcpus, >>> after that we do not need to flush tlb when obsolete pages >>> are zapped >> >> After that point batching is also not relevant anymore? > > no... without batching, we do not know how much time we will > spend to zap pages. It is not good for the case that > zap_all_pages is called in the vcpu context. > >> >> >> Still concerned about a similar case mentioned earlier: >> >> " >> Note the account for pages freed step after pages are actually >> freed: as discussed with Takuya, having pages freed and freed page >> accounting out of sync across mmu_lock is potentially problematic: >> kvm->arch.n_used_mmu_pages and friends do not reflect reality which can >> cause problems for SLAB freeing and page allocation throttling. >> " >> >> This is a real problem, if you decrease n_used_mmu_pages at >> kvm_mmu_prepare_zap_page, but only actually free pages later >> at kvm_mmu_commit_zap_page, there is the possibility of allowing >> a huge number to be retained. There should be a maximum number of pages >> at invalid_list. >> >> (even higher possibility if you schedule without freeing pages reported >> as released!). >> >>> Note: kvm_mmu_commit_zap_page is still needed before free >>> the pages since other vcpus may be doing locklessly shadow >>> page walking > > Ah, yes, i agree with you. > > We can introduce a list, say kvm->arch.obsolte_pages, to link all of the > zapped-page, the page-shrink will free the page on that list first. > > Marcelo, if you do not have objection on patch 1 ~ 8 and 11, could you please > let them merged first, and do add some comments and tlb optimization later? Exclude patch 11 please, since it depends on the "collapse" optimization. -- 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: mxs: Include clk mxs header file
On Mon, May 27, 2013 at 12:28:25PM -0300, Fabio Estevam wrote: > Fix the following sparse warnings: > > drivers/clk/mxs/clk-imx28.c:72:5: warning: symbol 'mxs_saif_clkmux_select' > was not declared. Should it be static? > drivers/clk/mxs/clk-imx28.c:156:12: warning: symbol 'mx28_clocks_init' was > not declared. Should it be static? > > Signed-off-by: Fabio Estevam Acked-by: Shawn Guo > --- > drivers/clk/mxs/clk-imx28.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/clk/mxs/clk-imx28.c b/drivers/clk/mxs/clk-imx28.c > index d0e5eed..4faf0af 100644 > --- a/drivers/clk/mxs/clk-imx28.c > +++ b/drivers/clk/mxs/clk-imx28.c > @@ -10,6 +10,7 @@ > */ > > #include > +#include > #include > #include > #include > -- > 1.8.1.2 > > -- 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] usb: omap2430: fix memleak in err case
On 2013/5/29 1:40, Sergei Shtylyov wrote: > Hello. > > On 22-05-2013 7:30, Libo Chen wrote: > >> when omap_get_control_dev faild, we should release related platform_device > >> * Changelog from v1: >> * fix spell: s/fail/fails/, s/relational/related/ , thank Sergei >> > >It seems you've actually replaced "fail" with "faild", not "fails". sorry for my weak spell. thanks again, Libo > >> Signed-off-by: Libo Chen >> --- >> drivers/usb/musb/omap2430.c |3 ++- >> 1 files changed, 2 insertions(+), 1 deletions(-) > > WBR, Sergei > > > -- 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] memcg: don't initialize kmem-cache destroying work for root caches
On 05/29/2013 04:23 AM, Andrew Morton wrote:
> On Tue, 14 May 2013 16:38:38 +0400 Andrey Vagin wrote:
>
>> struct memcg_cache_params has a union. Different parts of this union are
>> used for root and non-root caches. A part with destroying work is used only
>> for non-root caches.
>
> That union is a bit dangerous. Perhaps it would be better to do
> something like
>
> --- a/include/linux/slab.h~a
> +++ a/include/linux/slab.h
> @@ -337,15 +337,17 @@ static __always_inline int kmalloc_size(
> struct memcg_cache_params {
> bool is_root_cache;
> union {
> - struct kmem_cache *memcg_caches[0];
> - struct {
> + struct memcg_root_cache {
> + struct kmem_cache *caches[0];
> + } memcg_root_cache;
> + struct memcg_child_cache {
> struct mem_cgroup *memcg;
> struct list_head list;
> struct kmem_cache *root_cache;
> bool dead;
> atomic_t nr_pages;
> struct work_struct destroy;
> - };
> + } memcg_child_cache;
> };
> };
>
> And then adopt the convention of selecting either memcg_root_cache or
> memcg_child_cache at the highest level then passing the more strongly
> typed pointer to callees.
>
Since it is already creating problems, yes, I agree.
I will try to cook up something 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/
Dead URL in Documentation/acpi/dsdt-override.txt
The domain name www.lesswatts.org in Documentation/acpi/dsdt-override.txt is unresolvable, so the URL is dead too. I found some good docs in this topic: http://wiki.debian.org/OverridingDSDT -- 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 RESEND] mtd: fix kfree bcm47xxsflash
On 2013/5/28 23:29, Andy Shevchenko wrote: > This is good fix, but I rather prefer not to see it in this shape. > See comments below. > > On Wed, May 22, 2013 at 6:51 AM, Libo Chen > wrote: >> >> mtd is just member of bcm47xxsflash, so we should free bcm47xxsflash not >> its member. >> >> Signed-off-by: Libo Chen >> Acked-by: Rafał Miłecki >> --- >> drivers/mtd/devices/bcm47xxsflash.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> * add Acked-by: Rafał Miłecki >> * change send list >> >> diff --git a/drivers/mtd/devices/bcm47xxsflash.c >> b/drivers/mtd/devices/bcm47xxsflash.c >> index 9526628..4aa9141 100644 >> --- a/drivers/mtd/devices/bcm47xxsflash.c >> +++ b/drivers/mtd/devices/bcm47xxsflash.c >> @@ -76,7 +76,7 @@ static int bcm47xxsflash_bcma_probe(struct platform_device >> *pdev) >> return 0; >> >> err_dev_reg: >> - kfree(&b47s->mtd); >> + kfree(b47s); >> out: >> return err; >> } > > What about to switch to devm_* and remove those labels and kfrees at all? > > Additionally you can add another patch to use module_platform_driver() > macro instead of module_init/exit. > ok, I will update later. thanks, Libo > -- > With Best Regards, > Andy Shevchenko > > . > -- 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] driver: tty: add missing unregister in err case
Libo Chen wrote: when platform_driver_register broken, we should unregister ucc_uart_driver Signed-off-by: Libo chen Acked-by: Timur Tabi Thanks for catching this. -- Timur Tabi -- 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] driver: tty: add missing unregister in err case
when platform_driver_register broken, we should unregister ucc_uart_driver
Signed-off-by: Libo chen
---
drivers/tty/serial/ucc_uart.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/tty/serial/ucc_uart.c b/drivers/tty/serial/ucc_uart.c
index 7355303..f86f447 100644
--- a/drivers/tty/serial/ucc_uart.c
+++ b/drivers/tty/serial/ucc_uart.c
@@ -1518,9 +1518,11 @@ static int __init ucc_uart_init(void)
}
ret = platform_driver_register(&ucc_uart_of_driver);
- if (ret)
+ if (ret) {
printk(KERN_ERR
"ucc-uart: could not register platform driver\n");
+ uart_unregister_driver(&ucc_uart_driver);
+ }
return ret;
}
--
1.7.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/
linux-next: manual merge of the trivial tree with the net-next tree
Hi Jiri,
Today's linux-next merge of the trivial tree got a conflict in
Documentation/networking/netlink_mmap.txt between commit 3dd17edea018
("doc:networking: Fix typo in documentation/networking") from the
net-next tree and commit f884ab15afdc ("doc: fix misspellings with
'codespell' tool") from the trivial tree.
The fix in the net-next tree was a superset of the one in the trivial
tree, so I used that and can carry the fix as necessary (no action is
required).
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
pgpj_bdHF4Lnx.pgp
Description: PGP signature
Re: [PATCH v3 4/9] media: davinci: vpif_capture: move the freeing of irq and global variables to remove()
Hi Prabhakar,
Thanks for the patch.
On Sunday 26 May 2013 17:30:07 Prabhakar Lad wrote:
> From: Lad, Prabhakar
>
> Ideally the freeing of irq's and the global variables needs to be
> done in the remove() rather than module_exit(), this patch moves
> the freeing up of irq's and freeing the memory allocated to channel
> objects to remove() callback of struct platform_driver.
>
> Signed-off-by: Lad, Prabhakar
> ---
> drivers/media/platform/davinci/vpif_capture.c | 31 ++
> 1 files changed, 13 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/media/platform/davinci/vpif_capture.c
> b/drivers/media/platform/davinci/vpif_capture.c index caaf4fe..f8b7304
> 100644
> --- a/drivers/media/platform/davinci/vpif_capture.c
> +++ b/drivers/media/platform/davinci/vpif_capture.c
> @@ -2225,17 +2225,29 @@ vpif_int_err:
> */
> static int vpif_remove(struct platform_device *device)
> {
> - int i;
> + struct platform_device *pdev;
> struct channel_obj *ch;
> + struct resource *res;
> + int irq_num, i = 0;
> +
> + pdev = container_of(vpif_dev, struct platform_device, dev);
As Sergei mentioned, the platform device is already passed to the function as
an argument.
> + while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, i))) {
> + for (irq_num = res->start; irq_num <= res->end; irq_num++)
> + free_irq(irq_num,
> + (void *)(&vpif_obj.dev[i]->channel_id));
A quick look at board code shows that each IRQ resource contains a single IRQ.
The second loop could thus be removed. You could also add another patch to
perform similar cleanup for the probe code.
> + i++;
> + }
>
> v4l2_device_unregister(&vpif_obj.v4l2_dev);
>
> + kfree(vpif_obj.sd);
> /* un-register device */
> for (i = 0; i < VPIF_CAPTURE_MAX_DEVICES; i++) {
> /* Get the pointer to the channel object */
> ch = vpif_obj.dev[i];
> /* Unregister video device */
> video_unregister_device(ch->video_dev);
> + kfree(vpif_obj.dev[i]);
> }
> return 0;
> }
> @@ -2347,24 +2359,7 @@ static __init int vpif_init(void)
> */
> static void vpif_cleanup(void)
> {
> - struct platform_device *pdev;
> - struct resource *res;
> - int irq_num;
> - int i = 0;
> -
> - pdev = container_of(vpif_dev, struct platform_device, dev);
> - while ((res = platform_get_resource(pdev, IORESOURCE_IRQ, i))) {
> - for (irq_num = res->start; irq_num <= res->end; irq_num++)
> - free_irq(irq_num,
> - (void *)(&vpif_obj.dev[i]->channel_id));
> - i++;
> - }
> -
> platform_driver_unregister(&vpif_driver);
> -
> - kfree(vpif_obj.sd);
> - for (i = 0; i < VPIF_CAPTURE_MAX_DEVICES; i++)
> - kfree(vpif_obj.dev[i]);
> }
>
> /* Function for module initialization and cleanup */
--
Regards,
Laurent Pinchart
--
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 7/8] genirq: generic chip: Add linear irq domain support
On Mon, 06 May 2013 14:30:27 -, Thomas Gleixner wrote:
> Provide infrastructure for irq chip implementations which work on
> linear irq domains.
>
> - Interface to allocate multiple generic chips which are associated to
> the irq domain.
>
> - Interface to get the generic chip pointer for a particular hardware
> interrupt in the domain.
>
> - irq domain mapping function to install the chip for a particular
> interrupt.
>
> Note: This lacks a removal function for now, but this is a draft patch
> the ARM folks to work on.
>
> [ Sebastian Hesselbarth: Mask cache and pointer math fixups ]
>
> Signed-off-by: Thomas Gleixner
Hi Thomas,
Acked-by: Grant Likely
But I have some comments below...
> ---
> include/linux/irq.h | 30 +++
> include/linux/irqdomain.h | 12 ++
> kernel/irq/generic-chip.c | 187
> --
> kernel/irq/irqdomain.c|6 -
> 4 files changed, 223 insertions(+), 12 deletions(-)
>
> Index: linux-2.6/include/linux/irq.h
> ===
> --- linux-2.6.orig/include/linux/irq.h
> +++ linux-2.6/include/linux/irq.h
> @@ -678,6 +678,8 @@ struct irq_chip_type {
> * @wake_active: Interrupt is marked as an wakeup from suspend source
> * @num_ct: Number of available irq_chip_type instances (usually 1)
> * @private: Private data for non generic chip callbacks
> + * @installed: bitfield to denote installed interrupts
> + * @domain: irq domain pointer
> * @list:List head for keeping track of instances
> * @chip_types: Array of interrupt irq_chip_types
> *
> @@ -699,6 +701,8 @@ struct irq_chip_generic {
> u32 wake_active;
> unsigned intnum_ct;
> void*private;
> + unsigned long installed;
This is probably something that the irqdomain should be keeping track of
internally, but that's an issue for a separate patch series.
[...]
> +struct irq_domain_ops irq_generic_chip_ops = {
> + .map = irq_map_generic_chip,
> + .xlate = irq_domain_xlate_onecell,
As discussed on IRC, should use onetwocell here for greater
compatibility with existing bindings.
Cheers,
g.
--
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 10/12] ipu_idmac: re-use dma_cookie_status()
On Mon, May 27, 2013 at 03:14:40PM +0300, Andy Shevchenko wrote:
> It's better to use generic dma_cookie_status() that allows user to get
> standard
> possible return codes independently of the DMAC driver in charge.
>
> Signed-off-by: Andy Shevchenko
> Cc: Shawn Guo
Acked-by: Shawn Guo
> ---
> drivers/dma/ipu/ipu_idmac.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/dma/ipu/ipu_idmac.c b/drivers/dma/ipu/ipu_idmac.c
> index d39c2cd..608d4a2 100644
> --- a/drivers/dma/ipu/ipu_idmac.c
> +++ b/drivers/dma/ipu/ipu_idmac.c
> @@ -1593,10 +1593,7 @@ static void idmac_free_chan_resources(struct dma_chan
> *chan)
> static enum dma_status idmac_tx_status(struct dma_chan *chan,
> dma_cookie_t cookie, struct dma_tx_state *txstate)
> {
> - dma_set_tx_state(txstate, chan->completed_cookie, chan->cookie, 0);
> - if (cookie != chan->cookie)
> - return DMA_ERROR;
> - return DMA_SUCCESS;
> + return dma_cookie_status(chan, cookie, txstate);
> }
>
> static int __init ipu_idmac_init(struct ipu *ipu)
> --
> 1.8.2.rc0.22.gb3600c3
>
--
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: map_init_section flushes incorrect pmd
On Wed, May 29, 2013 at 2:48 AM, Sricharan R wrote:
>
> On Tuesday 28 May 2013 07:37 PM, Will Deacon wrote:
> > On Tue, May 28, 2013 at 03:03:36PM +0100, Sricharan R wrote:
> >> On Tuesday 28 May 2013 06:35 PM, Will Deacon wrote:
> >>> On Tue, May 28, 2013 at 11:48:20AM +0100, Po-Yu Chuang wrote:
> This bug was introduced in commit e651eab0.
> Some v4/v5 platforms failed to boot due to this.
>
> Signed-off-by: Po-Yu Chuang
> ---
> arch/arm/mm/mmu.c |4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/mm/mmu.c b/arch/arm/mm/mmu.c
> index e0d8565..19a43f8 100644
> --- a/arch/arm/mm/mmu.c
> +++ b/arch/arm/mm/mmu.c
> @@ -620,6 +620,8 @@ static void __init map_init_section(pmd_t *pmd,
> unsigned long addr,
> unsigned long end, phys_addr_t phys,
> const struct mem_type *type)
> {
> + pmd_t *p = pmd;
> +
> #ifndef CONFIG_ARM_LPAE
> /*
> * In classic MMU format, puds and pmds are folded in to
> @@ -638,7 +640,7 @@ static void __init map_init_section(pmd_t *pmd,
> unsigned long addr,
> phys += SECTION_SIZE;
> } while (pmd++, addr += SECTION_SIZE, addr != end);
>
> - flush_pmd_entry(pmd);
> + flush_pmd_entry(p);
> >>> Wait, shouldn't this flush be *inside* the loop anyway? Otherwise we just
> >>> flush the cacheline containing the first pmd. The flushing code could also
> >>> flush to PoU instead of PoC for UP ARMv7, but that's an unrelated
> >>> optimisation.
> >>I think in LPAE this loop iterates once and non LPAE twice.
> >>So both the entries should be contained in same cache line right ?
> > Dunno, are there any guarantees about alignment of the starting pmd? Even
> > so, the function takes the range as parameters, so I don't think we
> > should tailor it to the caller. It may explain why this hasn't come up
> > sooner though.
> >
> > Will
>
> This function is not exposed outside. And the ranges passed to this is going
> to not more than 2 entries in any case. If we put the flush inside the loop,
> then we will end up doing an extra flush for the same line. Regarding the
> alignment, I think if the pgd base is aligned, then rest should be fine.
> Will have to check this.
>
> Regards,
> Sricharan
>
Hi ,
Catalin and Sricharan,
Thanks for your explanation.
Will,
I guess nobody noticed this because the MMU of later v7 processors
fetches page table
from D-cache. It even doesn't need to clean pmd to PoU.
Regards,
Po-Yu
--
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] x86: Fix adjust_range_size_mask calling position
On 05/28/2013 04:43 PM, Yinghai Lu wrote: >> >> Sorry, I'm not sure I understand what the above paragraph is trying to say. > > We merge the continuous range with same page size allow too early. > in the case > [mem 0x0020-0x3fff] page 2M > [mem 0x4000-0x7bff] page 2M > after merging them, will get > [mem 0x0020-0x7bff] page 2M > even we can use 1G page to map > [mem 0x4000-0x7bff] > > that will cause problem, because we map > [mem 0x7fe0-0x7fff] page 1G > [mem 0x7c00-0x7fdf] page 1G > with 1G page. > > so need to adjust page size at first before merge > [mem 0x0020-0x3fff] page 2M > [mem 0x4000-0x7bff] page 2M > What I meant with that is please update the description so someone uninitiated can follow the description, either now or in 5-10 years. -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 3/3] irqchip: Make versatile fpga irq driver a generic chip
This is an RFC patch to convert the versatile FPGA irq controller driver
to use generic irq chip. It builds on the series that extends the
generic chip code to allow a linear irq domain to contain one or more
generic irq chips so that each interrupt controller doesn't need to hand
code the generic chip setup.
I've written this as a proof of concept to see if the new generic irq
code does what it needs to. I had to extend it slightly to properly
handle the valid mask used by the versatile FPGA driver.
Tested on QEMU, but not on real hardware.
Signed-off-by: Grant Likely
Cc: Russell King
Cc: Linus Walleij
Cc: Thomas Gleixner
---
drivers/irqchip/Kconfig | 1 +
drivers/irqchip/irq-versatile-fpga.c | 104 +--
2 files changed, 39 insertions(+), 66 deletions(-)
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index 4a33351..8765502 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -14,6 +14,7 @@ config ARM_VIC
bool
select IRQ_DOMAIN
select MULTI_IRQ_HANDLER
+ select GENERIC_IRQ_CHIP
config ARM_VIC_NR
int
diff --git a/drivers/irqchip/irq-versatile-fpga.c
b/drivers/irqchip/irq-versatile-fpga.c
index 065b7a3..8c7097b 100644
--- a/drivers/irqchip/irq-versatile-fpga.c
+++ b/drivers/irqchip/irq-versatile-fpga.c
@@ -34,37 +34,18 @@
* @used_irqs: number of active IRQs on this controller
*/
struct fpga_irq_data {
- void __iomem *base;
- struct irq_chip chip;
- u32 valid;
struct irq_domain *domain;
- u8 used_irqs;
};
/* we cannot allocate memory when the controllers are initially registered */
static struct fpga_irq_data fpga_irq_devices[CONFIG_VERSATILE_FPGA_IRQ_NR];
static int fpga_irq_id;
-static void fpga_irq_mask(struct irq_data *d)
-{
- struct fpga_irq_data *f = irq_data_get_irq_chip_data(d);
- u32 mask = 1 << d->hwirq;
-
- writel(mask, f->base + IRQ_ENABLE_CLEAR);
-}
-
-static void fpga_irq_unmask(struct irq_data *d)
-{
- struct fpga_irq_data *f = irq_data_get_irq_chip_data(d);
- u32 mask = 1 << d->hwirq;
-
- writel(mask, f->base + IRQ_ENABLE_SET);
-}
-
static void fpga_irq_handle(unsigned int irq, struct irq_desc *desc)
{
- struct fpga_irq_data *f = irq_desc_get_handler_data(desc);
- u32 status = readl(f->base + IRQ_STATUS);
+ struct irq_domain *domain = irq_desc_get_handler_data(desc);
+ struct irq_chip_generic *gc = irq_get_domain_generic_chip(domain, 0);
+ u32 status = readl(gc->reg_base + IRQ_STATUS);
if (status == 0) {
do_bad_IRQ(irq, desc);
@@ -74,7 +55,7 @@ static void fpga_irq_handle(unsigned int irq, struct irq_desc
*desc)
do {
irq = ffs(status) - 1;
status &= ~(1 << irq);
- generic_handle_irq(irq_find_mapping(f->domain, irq));
+ generic_handle_irq(irq_find_mapping(domain, irq));
} while (status);
}
@@ -85,11 +66,12 @@ static void fpga_irq_handle(unsigned int irq, struct
irq_desc *desc)
*/
static int handle_one_fpga(struct fpga_irq_data *f, struct pt_regs *regs)
{
+ struct irq_chip_generic *gc = irq_get_domain_generic_chip(f->domain, 0);
int handled = 0;
int irq;
u32 status;
- while ((status = readl(f->base + IRQ_STATUS))) {
+ while ((status = readl(gc->reg_base + IRQ_STATUS))) {
irq = ffs(status) - 1;
handle_IRQ(irq_find_mapping(f->domain, irq), regs);
handled = 1;
@@ -112,63 +94,53 @@ asmlinkage void __exception_irq_entry
fpga_handle_irq(struct pt_regs *regs)
} while (handled);
}
-static int fpga_irqdomain_map(struct irq_domain *d, unsigned int irq,
- irq_hw_number_t hwirq)
-{
- struct fpga_irq_data *f = d->host_data;
-
- /* Skip invalid IRQs, only register handlers for the real ones */
- if (!(f->valid & BIT(hwirq)))
- return -ENOTSUPP;
- irq_set_chip_data(irq, f);
- irq_set_chip_and_handler(irq, &f->chip,
- handle_level_irq);
- set_irq_flags(irq, IRQF_VALID | IRQF_PROBE);
- return 0;
-}
-
-static struct irq_domain_ops fpga_irqdomain_ops = {
- .map = fpga_irqdomain_map,
- .xlate = irq_domain_xlate_onetwocell,
-};
-
void __init fpga_irq_init(void __iomem *base, const char *name, int irq_start,
int parent_irq, u32 valid, struct device_node *node)
{
+ struct irq_chip_generic *gc;
struct fpga_irq_data *f;
- int i;
+ int ret;
if (fpga_irq_id >= ARRAY_SIZE(fpga_irq_devices)) {
pr_err("%s: too few FPGA IRQ controllers, increase
CONFIG_VERSATILE_FPGA_IRQ_NR\n", __func__);
return;
}
f = &fpga_irq_devices[fpga_irq_id];
- f->base = base;
- f->chip.name = name;
- f->chip.irq_ack = fpga_irq_mask;
- f->chip.irq_mask = fp
[PATCH 0/3] Try out the irqdomain + generic chip integration series
Hi Thomas, Rather than just straight reviewing the generic irq chip patch series, I tried it out by converting another driver to use it. As far as I've been able to tell it does the right thing and you can have my ack. The first patch in this series adds another feature needed by the versatile driver. Patch 2 should be okay, but I'd like to get an ack from Ben before it gets applied. I need to get someone to test patch 3 on hardware before you pick up that one. Oh, and I'll reply directly to patch 7 of your series with an ack and a minor comment. Cheers, g. -- 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/3] irqdomain: Relax failure path on setting up mappings
Commit 98aa468e, "irqdomain: Support for static IRQ mapping and
association" introduced an API for directly associating blocks of hwirqs
to linux irqs. However, if any irq in that block failed to map (say if
the mapping functions returns an error because the irq is already
mapped) then the whole thing will fail and roll back. This is probably
too aggressive since there are valid reasons why a mapping may fail.
ie. Firmware may have a particular IRQ marked as unusable.
This patch drops the error path out of irq_domain_associate(). If a
mapping fails, then it is simply skipped. There is no reason to fail the
entire allocation.
Signed-off-by: Grant Likely
Cc: Paul Mundt
Cc: Benjamin Herrenschmidt
Cc: Thomas Gleixner
---
kernel/irq/irqdomain.c | 29 +++--
1 file changed, 3 insertions(+), 26 deletions(-)
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 1db9e70..428ae1db 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -455,28 +455,9 @@ int irq_domain_associate_many(struct irq_domain *domain,
unsigned int irq_base,
irq_data->domain = domain;
if (domain->ops->map) {
ret = domain->ops->map(domain, virq, hwirq);
- if (ret != 0) {
- /*
-* If map() returns -EPERM, this interrupt is
protected
-* by the firmware or some other service and
shall not
-* be mapped.
-*
-* Since on some platforms we blindly try to
map everything
-* we end up with a log full of backtraces.
-*
-* So instead, we silently fail on -EPERM, it
is the
-* responsibility of the PIC driver to display
a relevant
-* message if needed.
-*/
- if (ret != -EPERM) {
- pr_err("irq-%i==>hwirq-0x%lx mapping
failed: %d\n",
- virq, hwirq, ret);
- WARN_ON(1);
- }
- irq_data->domain = NULL;
- irq_data->hwirq = 0;
- goto err_unmap;
- }
+ /* Some maps are refused; this is probably just fine */
+ if (ret)
+ continue;
}
switch (domain->revmap_type) {
@@ -495,10 +476,6 @@ int irq_domain_associate_many(struct irq_domain *domain,
unsigned int irq_base,
}
return 0;
-
- err_unmap:
- irq_domain_disassociate_many(domain, irq_base, i);
- return -EINVAL;
}
EXPORT_SYMBOL_GPL(irq_domain_associate_many);
--
1.8.1.2
--
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/3] irqchip: Add mask to block out invalid irqs
Some controllers have irqs that aren't wired up and must never be used.
For the generic chip attached to an irq_domain this provides a mask that
can be used to block out particular irqs so that they never get mapped.
Signed-off-by: Grant Likely
Cc: Thomas Gleixner
---
include/linux/irq.h | 2 ++
kernel/irq/generic-chip.c | 3 +++
2 files changed, 5 insertions(+)
diff --git a/include/linux/irq.h b/include/linux/irq.h
index af7052c..298a9b9 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -679,6 +679,7 @@ struct irq_chip_type {
* @num_ct:Number of available irq_chip_type instances (usually 1)
* @private: Private data for non generic chip callbacks
* @installed: bitfield to denote installed interrupts
+ * @unused:bitfield to denote unused interrupts
* @domain:irq domain pointer
* @list: List head for keeping track of instances
* @chip_types:Array of interrupt irq_chip_types
@@ -702,6 +703,7 @@ struct irq_chip_generic {
unsigned intnum_ct;
void*private;
unsigned long installed;
+ unsigned long unused;
struct irq_domain *domain;
struct list_headlist;
struct irq_chip_typechip_types[0];
diff --git a/kernel/irq/generic-chip.c b/kernel/irq/generic-chip.c
index 8e4d6bd..7b44aa2 100644
--- a/kernel/irq/generic-chip.c
+++ b/kernel/irq/generic-chip.c
@@ -359,6 +359,9 @@ static int irq_map_generic_chip(struct irq_domain *d,
unsigned int virq,
idx = hw_irq % dgc->irqs_per_chip;
+ if (test_bit(idx, &gc->unused))
+ return -ENOTSUPP;
+
if (test_bit(idx, &gc->installed))
return -EBUSY;
--
1.8.1.2
--
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] arm64: compiling issue for allmodconfig, need "asm/parport.h" by "drivers/parport/parport_pc.c"
On 05/29/2013 01:02 AM, Catalin Marinas wrote: >> > >> > After check the Kconfig in drivers, we can find quite a few using long >> > list args which related with ARCH. >> > >> > And they are not only depend on ARCHs, but also depend on another >> > things (e.g. VGA_CONSOL also depend on !4xx && !8xx, and another >> > combinations). > Given this dependency is on the negation of that symbol, you just remove > it and have a "depends on HAVE_VGA_CONSOLE". The few architectures that > need it will have to define it (X86, ARM with a few configurations). > it is "depends on !4xx && !8xx && !SPARC && !M68K && !PARISC && !FRV && !SUPERH && !BLACKFIN && !AVR32 && !MN10300 && (!ARM || ARCH_FOOTBRIDGE || ARCH_INTEGRATOR || ARCH_NETWINDER)" So, not only x86, ARM, but also s390, xtensa, alpha, cris, h8300, ia64, mips... (at least, we do not know, they whether need it or not). >> > We also can find another long list for depend on, but not related with >> > ARCH. >> > >> > They seems not quit difficult for reading (in fact, if we separate them >> > into pieces and let them spread into another areas, the reader will not >> > see the whole dependency clearly) >> > >> > For fixing bug, better as local as possible, as independent as possible, >> > it will be OK if only add !ARM64 for PARPORT_PC depend on, and it has >> > no any negative effect. But if we define CONFIG_HAVE_*, we have to let >> > it related with multiple platforms. >> > >> > For design: if can bear current design, better not to touch it, I think >> > current design is still sustainable, and not complex for understanding, >> > so not need redesign. > We usually clean some of these as we hit them, otherwise people forget > about the clean-up later ;). In fact, I have sent another configuration modification about disabling CONFIG_BUG. it is in discussing... We are sure most of architectures do not need CONFIG_BUG, but for VGA_CONSOLE, we can not be sure most of architectures do not need it. For CONFIG_BUG issue, it will make noisy for most of architectures, but for VGA_CONSOLE issue, at least now, it is only effect with arm64. For CONFIG_BUG issue, it seems we can not provide a satisfied fixing if not get rid of it, but for VGA_CONSOLE issue, at least we have a complete fixing way for it. And now for CONFIG_BUG issue, it is still continuing discussing, and it seems that can not get a result quickly. So for VGA_CONSOLE... ;-) Thanks. -- Chen Gang Asianux Corporation -- 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/2] Drivers: hv: vmbus: Implement multi-channel support
> -Original Message- > From: K. Y. Srinivasan [mailto:k...@microsoft.com] > Sent: Thursday, May 23, 2013 3:02 PM > To: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; > de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; > jasow...@redhat.com > Cc: KY Srinivasan > Subject: [PATCH V2 0/2] Drivers: hv: vmbus: Implement multi-channel support > > This patch-set implements multi-channel support for Hyper-V devices. > > Earlier, these two patches were sent out as part of a larger patch-set > that included relevant changes in the storage driver. > > In this version of the patch, I have fixed a race condition in the code that > opens the sub-channels. > > K. Y. Srinivasan (2): > Drivers: hv: vmbus: Implement multi-channel support > Drivers: hv: Add the GUID fot synthetic fibre channel device > > drivers/hv/channel.c | 50 +-- > drivers/hv/channel_mgmt.c | 119 > +++-- > drivers/hv/connection.c | 14 + > include/linux/hyperv.h| 70 ++ > 4 files changed, 245 insertions(+), 8 deletions(-) Greg, You had acked the previous version of these patches that I had sent along with the storage driver patches that used this infrastructure. We are going to be submitting network driver patches that will use this infrastructure to implement VRSS (virtual receive side scaling) and that is the reason I chose to not tie up these vmbus patches with the storvsc patches. Please let me know if you are ok with the changes I have made in this version. Once these patches are committed, we will submit both storage and networking patches that use this infrastructure. Regards, K. Y > > -- > 1.7.4.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 2/2] ftrace: Use the rcu _notrace variants for rcu_dereference_raw() and friends
On Tue, May 28, 2013 at 02:38:43PM -0400, Steven Rostedt wrote:
> As rcu_dereference_raw() under RCU debug config options can add quite a
> bit of checks, and that tracing uses rcu_dereference_raw(), these checks
> happen with the function tracer. The function tracer also happens to trace
> these debug checks too. This added overhead can livelock the system.
>
> Have the function tracer use the new RCU _notrace equivalents that do
> not do the debug checks for RCU.
>
> Signed-off-by: Steven Rostedt
Looks good to me!
Acked-by: Paul E. McKenney
> Index: linux-trace.git/kernel/trace/ftrace.c
> ===
> --- linux-trace.git.orig/kernel/trace/ftrace.c
> +++ linux-trace.git/kernel/trace/ftrace.c
> @@ -120,22 +120,22 @@ static void ftrace_ops_no_ops(unsigned l
>
> /*
> * Traverse the ftrace_global_list, invoking all entries. The reason that we
> - * can use rcu_dereference_raw() is that elements removed from this list
> + * can use rcu_dereference_raw_notrace() is that elements removed from this
> list
> * are simply leaked, so there is no need to interact with a grace-period
> - * mechanism. The rcu_dereference_raw() calls are needed to handle
> + * mechanism. The rcu_dereference_raw_notrace() calls are needed to handle
> * concurrent insertions into the ftrace_global_list.
> *
> * Silly Alpha and silly pointer-speculation compiler optimizations!
> */
> #define do_for_each_ftrace_op(op, list) \
> - op = rcu_dereference_raw(list); \
> + op = rcu_dereference_raw_notrace(list); \
> do
>
> /*
> * Optimized for just a single item in the list (as that is the normal case).
> */
> #define while_for_each_ftrace_op(op) \
> - while (likely(op = rcu_dereference_raw((op)->next)) && \
> + while (likely(op = rcu_dereference_raw_notrace((op)->next)) && \
> unlikely((op) != &ftrace_list_end))
>
> static inline void ftrace_ops_init(struct ftrace_ops *ops)
> @@ -779,7 +779,7 @@ ftrace_find_profiled_func(struct ftrace_
> if (hlist_empty(hhd))
> return NULL;
>
> - hlist_for_each_entry_rcu(rec, hhd, node) {
> + hlist_for_each_entry_rcu_notrace(rec, hhd, node) {
> if (rec->ip == ip)
> return rec;
> }
> @@ -1165,7 +1165,7 @@ ftrace_lookup_ip(struct ftrace_hash *has
>
> hhd = &hash->buckets[key];
>
> - hlist_for_each_entry_rcu(entry, hhd, hlist) {
> + hlist_for_each_entry_rcu_notrace(entry, hhd, hlist) {
> if (entry->ip == ip)
> return entry;
> }
> @@ -1422,8 +1422,8 @@ ftrace_ops_test(struct ftrace_ops *ops,
> struct ftrace_hash *notrace_hash;
> int ret;
>
> - filter_hash = rcu_dereference_raw(ops->filter_hash);
> - notrace_hash = rcu_dereference_raw(ops->notrace_hash);
> + filter_hash = rcu_dereference_raw_notrace(ops->filter_hash);
> + notrace_hash = rcu_dereference_raw_notrace(ops->notrace_hash);
>
> if ((ftrace_hash_empty(filter_hash) ||
>ftrace_lookup_ip(filter_hash, ip)) &&
> @@ -2920,7 +2920,7 @@ static void function_trace_probe_call(un
>* on the hash. rcu_read_lock is too dangerous here.
>*/
> preempt_disable_notrace();
> - hlist_for_each_entry_rcu(entry, hhd, node) {
> + hlist_for_each_entry_rcu_notrace(entry, hhd, node) {
> if (entry->ip == ip)
> entry->ops->func(ip, parent_ip, &entry->data);
> }
>
--
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/2] rcu: Add _notrace variation of rcu_dereference_raw() and hlist_for_each_entry_rcu()
On Tue, May 28, 2013 at 02:38:42PM -0400, Steven Rostedt wrote: > As rcu_dereference_raw() under RCU debug config options can add quite a > bit of checks, and that tracing uses rcu_dereference_raw(), these checks > happen with the function tracer. The function tracer also happens to trace > these debug checks too. This added overhead can livelock the system. > > Add a new interface to RCU for both rcu_dereference_raw_notrace() as well > as hlist_for_each_entry_rcu_notrace() as the hlist iterator uses the > rcu_dereference_raw() as well, and is used a bit with the function tracer. > > Signed-off-by: Steven Rostedt Much nicer! Acked-by: Paul E. McKenney > Index: linux-trace.git/include/linux/rculist.h > === > --- linux-trace.git.orig/include/linux/rculist.h > +++ linux-trace.git/include/linux/rculist.h > @@ -461,6 +461,26 @@ static inline void hlist_add_after_rcu(s > &(pos)->member)), typeof(*(pos)), member)) > > /** > + * hlist_for_each_entry_rcu_notrace - iterate over rcu list of given type > (for tracing) > + * @pos: the type * to use as a loop cursor. > + * @head:the head for your list. > + * @member: the name of the hlist_node within the struct. > + * > + * This list-traversal primitive may safely run concurrently with > + * the _rcu list-mutation primitives such as hlist_add_head_rcu() > + * as long as the traversal is guarded by rcu_read_lock(). > + * > + * This is the same as hlist_for_each_entry_rcu() except that it does > + * not do any RCU debugging or tracing. > + */ > +#define hlist_for_each_entry_rcu_notrace(pos, head, member) > \ > + for (pos = hlist_entry_safe > (rcu_dereference_raw_notrace(hlist_first_rcu(head)),\ > + typeof(*(pos)), member);\ > + pos;\ > + pos = > hlist_entry_safe(rcu_dereference_raw_notrace(hlist_next_rcu(\ > + &(pos)->member)), typeof(*(pos)), member)) > + > +/** > * hlist_for_each_entry_rcu_bh - iterate over rcu list of given type > * @pos: the type * to use as a loop cursor. > * @head:the head for your list. > Index: linux-trace.git/include/linux/rcupdate.h > === > --- linux-trace.git.orig/include/linux/rcupdate.h > +++ linux-trace.git/include/linux/rcupdate.h > @@ -640,6 +640,15 @@ static inline void rcu_preempt_sleep_che > > #define rcu_dereference_raw(p) rcu_dereference_check(p, 1) /*@@@ needed? > @@@*/ > > +/* > + * The tracing infrastructure traces RCU (we want that), but unfortunately > + * some of the RCU checks causes tracing to lock up the system. > + * > + * The tracing version of rcu_dereference_raw() must not call > + * rcu_read_lock_held(). > + */ > +#define rcu_dereference_raw_notrace(p) __rcu_dereference_check((p), 1, __rcu) > + > /** > * rcu_access_index() - fetch RCU index with no dereferencing > * @p: The index to read > -- 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: [RFC PATCH v1 0/5] BTRFS hot relocation support
Kent Overstreet posted on Tue, 28 May 2013 17:38:15 -0700 as excerpted: > On Tue, May 21, 2013 at 02:22:34AM +, Duncan wrote: >> zwu.kernel posted on Mon, 20 May 2013 23:11:22 +0800 as excerpted: >> >> > The patchset is trying to introduce hot relocation support for BTRFS. >> >> One advantage of a filesystem implementation, as opposed to bcache or >> dmcache, is arguably a corner-case, but it's /my/ corner-case, so... >> >> I run an intr*-less (I guess technically, empty initramfs) monolithic- >> kernel boot [so] any user-space-required-to- mount-root is out [...] >> >> Much like md before it, btrfs, while normally requiring the user-space- >> required device-scan to properly handle multiple devices, has kernel- >> command-line options that allow direct kernel multi-device assembly >> without the help of early-userspace/initr*. Just a note that while btrfs is /supposed/ to have that functionality, I'm actually trying to make it work now, and failing (I can get it to work only with rootflags=degraded, which then of course screws the sync between the devices, losing the point of multi-device mirroring). As (about a year ago when I brought it up then) someone else (btrfs dev) mentioned not being able to get rootflags=dev=... to work on the kernel command line with btrfs as well, I assume that functionality is broken due to some as yet un-addressed bug, hopefully to be fixed by the time btrfs is finally declared stable. However, that exchange from a year ago suggests it's not a particularly high priority... Meanwhile, I'm working on switching to a very minimal (dracut-based but cut WAY down) initramfs now. Basically only enough to mount the btrfs multi-device raid1 mirror since the kernel commandline rootflags method appears to be broken, but still with a monolithic kernel, etc, so REALLY quite minimal, indeed. (Once I get the semi-automated dracut host-only no-kernel with most-default-modules-omitted version working to give me a base pattern to work with, I may well switch to a hand assembled and kernel-built initramfs, trimming it down even further.) Hopefully someday the btrfs or rootflags kernel command-line bug will be fixed and I can go initr*less again. So in terms of bcache, for me personally for now, I could in theory add it to the minimal initr*. But there's certainly others running initr*- less as well, and I'd prefer to be in that class myself once again at some point. (When gentoo devs suggested forcing initr* for the separate / usr case, users raised QUITE a ruckus, so initr*less may be a minority case, but there's still quite a few out there, systemd's universe- engulfing gray-goo to the contrary or not.) So there's certainly people out there running initr*less who could make use of some sort of hot-data-cache-device functionality, if it's available to them. > I wouldn't be averse to adding such functionality to bcache, provided it > could be done reasonably cleanly/sensibly. It's not high on my list but > I'd accept patches :) Unfortunately I'm more an admin type than coder. I know my way around a Linux system well enough to confidently troubleshoot and trace bugs, but for anything other than shell-script, only in the trivial case can I actually file an appropriate bugfix patch and feature-patching is right out. So unfortunately, while I'm interested, such a patch can't come from me. =:^( But should anyone else with interest AND the ability be reading... =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- 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] ACPI: Fix potential NULL pointer dereference in acpi_processor_add()
On 2013-5-29 7:30, Rafael J. Wysocki wrote:
> On Thursday, May 23, 2013 08:44:26 PM Hanjun Guo wrote:
>> In acpi_processor_add(), get_cpu_device() will return NULL sometimes,
>> although the chances are small, I think it should be fixed.
>>
>> Signed-off-by: Hanjun Guo
>
> This patch isn't necessary any more after the changes queued up for 3.11
> in the acpi-hotplug branch of the linux-pm.git tree.
Ok, I noticed your patch set, just drop my patch.
Thanks
Hanjun
>
> Thanks,
> Rafael
>
>
>> ---
>> drivers/acpi/processor_driver.c |4
>> 1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/acpi/processor_driver.c
>> b/drivers/acpi/processor_driver.c
>> index bec717f..dd64f23 100644
>> --- a/drivers/acpi/processor_driver.c
>> +++ b/drivers/acpi/processor_driver.c
>> @@ -579,6 +579,10 @@ static int __cpuinit acpi_processor_add(struct
>> acpi_device
>> *device)
>> per_cpu(processors, pr->id) = pr;
>>
>> dev = get_cpu_device(pr->id);
>> + if (!dev) {
>> + result = -ENODEV;
>> + goto err_clear_processor;
>> + }
>> if (sysfs_create_link(&device->dev.kobj, &dev->kobj, "sysdev")) {
>> result = -EFAULT;
>> goto err_clear_processor;
>>
--
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: [RFC] Add co-maintainer for fbdev
On Wednesday, May 29, 2013 6:20 AM, Arnd Bergmann wrote: > On Monday 27 May 2013, Florian Tobias Schandinat wrote: > > >> On Fri, May 24, 2013 at 8:38 AM, Jean-Christophe PLAGNIOL-VILLARD > > >> wrote: > > >>> Hi Florian, > > >>> > > >>> As you seems very busy I'd like to propose the help you to > > >>> handle the > > >>> fbdev subsystem to easier the rich of the fbdev patch to Linus > > >>> > > >>> As I'm working on fbdev on at91 and others and already > > >>> Co-Maintain the > > >>> at91 mach on ARM > > >>> > > >>> And if you are not willing to continue I could take over > > > > Yeah, it would be great if you could help, at the moment I get barely > > any sleep, let alone that I could keep up with the majority of mail I > > get. I'll let you decide whether you want to be sole maintainer or not. > > For any bigger subsystems, it's good practice to have two maintainers, > even if one of them does all the work. I think it makes sense to have > Jean-Christophe as the primary maintainer and owner of the git tree, > but it may also be good to have you or Tomi listed as a second maintainer > for times when Jean-Christophe isn't available. Hi Arnd, I agree with Arnd's opinion. It looks good to have Florian or Tomi listed as a second maintainer. Best regards, Jingoo Han > > I don't know how many patches you'd expect per release, maybe just one > person is enough after all. > > Arnd > -- > To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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] rcu: fix a race in hlist_nulls_for_each_entry_rcu macro
On Tue, May 28, 2013 at 05:34:53PM -0700, Eric Dumazet wrote:
> On Tue, 2013-05-28 at 13:10 +0400, Roman Gushchin wrote:
> > On 28.05.2013 04:12, Eric Dumazet wrote:
>
> > > Adding a barrier() is probably what we want.
> >
> > I agree, inserting barrier() is also a correct and working fix.
>
> Yeah, but I can not find a clean way to put it inside the "for (;;)"
>
> for (barrier();;) ->
>
> error: expected expression before ‘__asm__’
>
> No user currently does :
>
> if (condition)
> hlist_nulls_for_each_entry_rcu(tpos, pos, head, member)
>
> But who knows...
I still have my earlier question, but I suggest "({ barrier(); XXX })"
to put the barrier into the for loop, either in the second or third
clause, where XXX was the original second or third clause.
Thanx, Paul
--
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 tip/core/rcu 6/7] rcu: Drive quiescent-state-forcing delay from HZ
On Tue, May 28, 2013 at 12:07:42PM +0200, Ingo Molnar wrote:
>
> * Paul E. McKenney wrote:
>
> > On Wed, May 15, 2013 at 11:20:55AM +0200, Ingo Molnar wrote:
> > >
> > > * Paul E. McKenney wrote:
> > >
> > > > rcu: Fix comparison sense in rcu_needs_cpu()
> > > >
> > > > Commit c0f4dfd4f (rcu: Make RCU_FAST_NO_HZ take advantage of numbered
> > > > callbacks) introduced a bug that can result in excessively long grace
> > > > periods. This bug reverse the senes of the "if" statement checking
> > > > for lazy callbacks, so that RCU takes a lazy approach when there are
> > > > in fact non-lazy callbacks. This can result in excessive boot, suspend,
> > > > and resume times.
> > > >
> > > > This commit therefore fixes the sense of this "if" statement.
> > > >
> > > > Reported-by: Borislav Petkov
> > > > Reported-by: Bj?rn Mork
> > > > Reported-by: Joerg Roedel
> > > > Signed-off-by: Paul E. McKenney
> > > >
> > > > diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
> > > > index 170814d..6d939a6 100644
> > > > --- a/kernel/rcutree_plugin.h
> > > > +++ b/kernel/rcutree_plugin.h
> > > > @@ -1667,7 +1667,7 @@ int rcu_needs_cpu(int cpu, unsigned long *dj)
> > > > rdtp->last_accelerate = jiffies;
> > > >
> > > > /* Request timer delay depending on laziness, and round. */
> > > > - if (rdtp->all_lazy) {
> > > > + if (!rdtp->all_lazy) {
> > > > *dj = round_up(rcu_idle_gp_delay + jiffies,
> > > >rcu_idle_gp_delay) - jiffies;
> > >
> > > Neat - could this explain sporadic long (but not infinite) boot times
> > > with
> > > NOHZ_FULL?
> > >
> > > We changed HZ to be at least 1 Hz pretty recently, which might have
> > > worked
> > > around this bug.
> >
> > Quite possibly...
> >
> > Of course, I don't see the boot slowdowns in my testing. :-/
>
> They were pretty sporadic and only popped up (and down) during randconfig
> testing. Simple unrelated changes to the .config made them go away -
> heisenbugs.
I can believe that... The system has to be very quiet for this bug to
significantly slow down boot. Interrupts scattered across CPUs (for
example) would tend to force RCU's state machine forward.
Thanx, Paul
> Thanks,
>
> Ingo
>
--
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] TPM: fix regression caused by section type conflict of tpm_dev_release() in ppc builds
On Mon, 27 May 2013, Peter H?we wrote: > Hi James, > > The following changes since commit 5b88e270253db6d817e6a2f61909d1e53620e990: > > maintainers: Remove Kent from maintainers > > are available in the git repository at: > > git://github.com/PeterHuewe/linux-tpmdd.git for-james > > for you to fetch changes up to e2fa3d799b7471f00adae59ff36260ad8237929f: > > tpm: fix regression caused by section type conflict of tpm_dev_release() in > ppc builds Pulled, thanks. -- James Morris -- 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 v5] media: i2c: tvp514x: add OF support
Hi Prabhakar,
Thanks for the patch.
On Sunday 26 May 2013 18:49:46 Prabhakar Lad wrote:
> From: Lad, Prabhakar
>
> add OF support for the tvp514x driver.
>
> Signed-off-by: Lad, Prabhakar
> Cc: Hans Verkuil
> Cc: Laurent Pinchart
> Cc: Mauro Carvalho Chehab
> Cc: Guennadi Liakhovetski
> Cc: Sylwester Nawrocki
> Cc: Sakari Ailus
> Cc: Grant Likely
> Cc: Rob Herring
> Cc: Rob Landley
> Cc: devicetree-disc...@lists.ozlabs.org
> Cc: linux-...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: davinci-linux-open-sou...@linux.davincidsp.com
Acked-by: Laurent Pinchart
(with two small comment below).
> ---
> Tested on da850-evm.
>
> RFC v1: https://patchwork.kernel.org/patch/2030061/
> RFC v2: https://patchwork.kernel.org/patch/2061811/
>
> Changes for current version from RFC v2:
> 1: Fixed review comments pointed by Sylwester.
>
> Changes for v2:
> 1: Listed all the compatible property values in the documentation text
> file. 2: Removed "-decoder" from compatible property values.
> 3: Added a reference to the V4L2 DT bindings documentation to explain
> what the port and endpoint nodes are for.
> 4: Fixed some Nits pointed by Laurent.
> 5: Removed unnecessary header file includes and sort them alphabetically.
>
> Changes for v3:
> 1: Rebased on patch https://patchwork.kernel.org/patch/2539411/
>
> Changes for v4:
> 1: added missing call for of_node_put().
> 2: Rebased the patch on v3.11.
>
> Changes for v5:
> 1: Fixed calling to a wrong label.
>
> .../devicetree/bindings/media/i2c/tvp514x.txt | 45 ++
> drivers/media/i2c/tvp514x.c| 62 +++--
> 2 files changed, 101 insertions(+), 6 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/media/i2c/tvp514x.txt
>
> diff --git a/Documentation/devicetree/bindings/media/i2c/tvp514x.txt
> b/Documentation/devicetree/bindings/media/i2c/tvp514x.txt new file mode
> 100644
> index 000..cc09424
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/tvp514x.txt
> @@ -0,0 +1,45 @@
> +* Texas Instruments TVP514x video decoder
> +
> +The TVP5146/TVP5146m2/TVP5147/TVP5147m1 device is high quality, single-chip
> +digital video decoder that digitizes and decodes all popular baseband
> analog +video formats into digital video component. The tvp514x decoder
> supports analog- +to-digital (A/D) conversion of component RGB and YPbPr
> signals as well as A/D +conversion and decoding of NTSC, PAL and SECAM
> composite and S-video into +component YCbCr.
> +
> +Required Properties :
> +- compatible : value should be either one among the following
> + (a) "ti,tvp5146" for tvp5146 decoder.
> + (b) "ti,tvp5146m2" for tvp5146m2 decoder.
> + (c) "ti,tvp5147" for tvp5147 decoder.
> + (d) "ti,tvp5147m1" for tvp5147m1 decoder.
> +
> +- hsync-active: HSYNC Polarity configuration for endpoint.
> +
> +- vsync-active: VSYNC Polarity configuration for endpoint.
> +
> +- pclk-sample: Clock polarity of the endpoint.
> +
> +
> +For further reading of port node refer
s/of port/on port/
s/refer/refer to/
> Documentation/devicetree/bindings/media/video-interfaces.txt.
> +
> +Example:
> +
> + i2c0@1c22000 {
> + ...
> + ...
> + tvp514x@5c {
> + compatible = "ti,tvp5146";
> + reg = <0x5c>;
> +
> + port {
> + tvp514x_1: endpoint {
> + hsync-active = <1>;
> + vsync-active = <1>;
> + pclk-sample = <0>;
> + };
> + };
> + };
> + ...
> + };
> diff --git a/drivers/media/i2c/tvp514x.c b/drivers/media/i2c/tvp514x.c
> index 7438e01..7ed999b 100644
> --- a/drivers/media/i2c/tvp514x.c
> +++ b/drivers/media/i2c/tvp514x.c
> @@ -39,6 +39,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -1055,6 +1056,42 @@ static struct tvp514x_decoder tvp514x_dev = {
>
> };
>
> +static struct tvp514x_platform_data *
> +tvp514x_get_pdata(struct i2c_client *client)
> +{
> + struct tvp514x_platform_data *pdata = NULL;
No need to initialize pdata to NULL.
> + struct v4l2_of_endpoint bus_cfg;
> + struct device_node *endpoint;
> + unsigned int flags;
> +
> + if (!IS_ENABLED(CONFIG_OF) || !client->dev.of_node)
> + return client->dev.platform_data;
> +
> + endpoint = v4l2_of_get_next_endpoint(client->dev.of_node, NULL);
> + if (!endpoint)
> + return NULL;
> +
> + pdata = devm_kzalloc(&client->dev, sizeof(*pdata), GFP_KERNEL);
> + if (!pdata)
> + goto done;
> +
> + v4l2_of_parse_endpoint(endpoint, &bus_cfg);
> + flags = bus_cfg.bus.parallel.flags;
> +
> + if (flags & V4L2_MBUS_HSYNC_ACTIVE_HIGH)
> + pdata->hs_polarity = 1;
> +
> + if (fl
Re: [PATCH v2] rcu: fix a race in hlist_nulls_for_each_entry_rcu macro
On Tue, May 28, 2013 at 01:10:46PM +0400, Roman Gushchin wrote:
> On 28.05.2013 04:12, Eric Dumazet wrote:
> >On Mon, 2013-05-27 at 21:55 +0400, Roman Gushchin wrote:
> >>Hi, Paul!
> >>
> >>>On 25.05.2013 15:37, Paul E. McKenney wrote:
> Again, I believe that your retry logic needs to extend back into the
> calling function for your some_func() example above.
> >>
> >>And what do you think about the following approach (diff below)?
> >>
> >>It seems to me, it's enough clear (especially with good accompanying
> >>comments)
> >>and produces a good binary code (without significant overhead).
> >>Also, we will remove a hidden reef in using rcu-protected (h)list traverses
> >>with restarts.
> >>
> >
> >>diff --git a/include/linux/rculist_nulls.h b/include/linux/rculist_nulls.h
> >>index 2ae1371..4af5ee5 100644
> >>--- a/include/linux/rculist_nulls.h
> >>+++ b/include/linux/rculist_nulls.h
> >>@@ -107,7 +107,8 @@ static inline void hlist_nulls_add_head_rcu(struct
> >>hlist_nulls_node *n,
> >>*
> >>*/
> >> #define hlist_nulls_for_each_entry_rcu(tpos, pos, head, member)
> >> \
> >>- for (pos = rcu_dereference_raw(hlist_nulls_first_rcu(head));
> >>\
> >>+ for (ACCESS_ONCE(*(head)),
> >>\
> >>+ pos = rcu_dereference_raw(hlist_nulls_first_rcu(head));
> >>\
> >> (!is_a_nulls(pos)) &&
> >> \
> >> ({ tpos = hlist_nulls_entry(pos, typeof(*tpos), member);
> >> 1; }); \
> >> pos = rcu_dereference_raw(hlist_nulls_next_rcu(pos)))
> >
> >It looks like this still relies on gcc being friendly here.
> >
> >I repeat again : @head here is a constant.
>
> No.
> Actually, there are two volatile objects: pointer to the first element (as a
> part of the head structure),
> and the first element by itself. So, to be strict, head as a structure
> contains a volatile field.
> Head->first should be treated as a volatile pointer to a volatile data. So,
> the whole head object is volatile.
>
> >
> >Macro already uses ACCESS_ONCE(), we only have to instruct gcc that
> >caching the value is forbidden if we restart the loop
> >(aka "goto begin;" see Documentation/RCU/rculist_nulls.txt line 146)
>
> My patch seems to be correct, because, ACCESS_ONCE(*(head)) will cause gcc to
> (re)read head data from the memory.
> According to gcc documentation:
> "A scalar volatile object is read when it is accessed in a void context:
> volatile int *src = somevalue;
> *src;
> Such expressions are rvalues, and GCC implements this as a read of the
> volatile object being pointed to."
> And this is exactly our case.
>
> >Adding a barrier() is probably what we want.
>
> I agree, inserting barrier() is also a correct and working fix.
I have to ask this question of both of you...
Are either of Eric's or Roman's fixes really guaranteed to work if gcc
elects not to inline the function containing the RCU list traversal?
Thanx, Paul
--
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: https://lkml.org/lkml/2013/2/1/531
On Wed, May 29, 2013 at 03:01:53AM +0200, Smart Weblications GmbH - Florian Wiessner wrote: > Am 23.05.2013 14:46, schrieb Matthew O'Connor: > > On 05/23/2013 06:24 AM, Smart Weblications GmbH - Florian Wiessner wrote: > >> node02:/ocfs2/usr/src/linux-3.4.46# cat drivers/net/bonding/bond_alb.c.rej > > My most sincere apologies - one more time, from a different mail server > > that hopefully won't go around changing my attachments. If this doesn't > > work I guess sendmail will be the next alternative. > > > > 3.4.47 got released without that included :-/?! > > https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.4.47 Yes, it missed that last release, I'll get a new one out when I get back from Japan next week. 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 v2 2/5] media: davinci: vpif: Convert to devm_* api
Hi Sergei,
On Sunday 26 May 2013 18:15:19 Sergei Shtylyov wrote:
> On 26-05-2013 4:49, Laurent Pinchart wrote:
> >> From: Lad, Prabhakar
> >>
> >> Use devm_ioremap_resource instead of reques_mem_region()/ioremap().
> >> This ensures more consistent error values and simplifies error paths.
> >>
> >> Signed-off-by: Lad, Prabhakar
> >> ---
> >>
> >> drivers/media/platform/davinci/vpif.c | 27
> >> ---
> >> 1 files changed, 4 insertions(+), 23 deletions(-)
> >>
> >> diff --git a/drivers/media/platform/davinci/vpif.c
> >> b/drivers/media/platform/davinci/vpif.c index 761c825..164c1b7 100644
> >> --- a/drivers/media/platform/davinci/vpif.c
> >> +++ b/drivers/media/platform/davinci/vpif.c
>
> [...]
>
> >> @@ -421,23 +419,12 @@ EXPORT_SYMBOL(vpif_channel_getfid);
> >>
> >> static int vpif_probe(struct platform_device *pdev)
> >> {
> >>
> >> - int status = 0;
> >> + static struct resource *res;
> >>
> >>res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> >>
> >> - if (!res)
> >> - return -ENOENT;
> >> -
> >> - res_len = resource_size(res);
> >> -
> >> - res = request_mem_region(res->start, res_len, res->name);
> >> - if (!res)
> >> - return -EBUSY;
> >> -
> >> - vpif_base = ioremap(res->start, res_len);
> >> - if (!vpif_base) {
> >> - status = -EBUSY;
> >> - goto fail;
> >> - }
> >> + vpif_base = devm_ioremap_resource(&pdev->dev, res);
> >> + if (IS_ERR(vpif_base))
> >> + return PTR_ERR(vpif_base);
> >
> > You're loosing the request_mem_region().
>
> He's not losing anything, first look at how devm_ioremp_resource() is
> defined.
My bad. I'm not sure where I got that idea from. Thanks for pointing out the
mistake.
> > You should use devm_request_and_ioremap()
>
> Already deprecated by now.
>
> > function instead of devm_ioremap_resource(). With that change,
> >
> > Acked-by: Laurent Pinchart
--
Regards,
Laurent Pinchart
--
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 04/21] Generic percpu refcounting
Yo, On Tue, May 28, 2013 at 04:47:28PM -0700, Kent Overstreet wrote: > > It'd be great if that is explained clearly in more intuitive way. The > > only actual explanation above is "modular arithmatic is commutative" > > which is a very compact way to put it and I really think it deserves > > an easier explanation. > > I'm not sure I know of any good way of explaining it intuitively, but > here's this at least... > > * (More precisely: because moduler arithmatic is commutative the sum of all > the > * pcpu_count vars will be equal to what it would have been if all the gets > and > * puts were done to a single integer, even if some of the percpu integers > * overflow or underflow). Yeah, that's much better. > And we can't do more puts than there have been gets - because the sum > can't be negative. So the most puts() we can do at any given time is the > real count, or sum of the percpu ref and atomic_t. > > Therefore, the amount the atomic_t can go negative is bounded by the > maximum value of the refcount. Ah, okay, I thought you were collecting the percpu counters directly into the global counter. You're staging it into a temp counter and then adding it into the global counter after the summing is complete. Yeap, that should be fine then. It'd be worthwhile to document the importance of not adding it directly to the global counter. > > I probably should have made it clearer. Sorry about that. tryget() > > is fine. I was curious about count() as it's always a bit dangerous a > > query interface which is racy and can return something unexpected like > > false zero or underflowed refcnt. > > Yeah, it is, it was intended just for the module code where it's only > used for the value lsmod shows. Let's document so then and limit the range returned. We require the refcnt to be alive and it'd be a good way to both protect from and deter creative usages. > > Let's just have percpu_ref_kill(ref, release) which puts the base ref > > and invokes release whenever it's done. > > Release has to be stored in struct percpu_ref() so it can be invoked > after a call_rcu() (percpu_ref_kill -> call_rcu() -> > percpu_ref_kill_rcu() -> percpu_ref_put()) so I'm passing it to > percpu_ref_init(), but yeah. Yeah, I'm a bit torn about where to put the release function. For me, as we have an API which is dedicated to killing a refcnt, it does make sense to put it there but it's really in the realm of bikeshedding so choose whatever you wanna choose. Thanks! -- tejun -- 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: https://lkml.org/lkml/2013/2/1/531
From: Smart Weblications GmbH - Florian Wiessner Date: Wed, 29 May 2013 03:01:53 +0200 > Am 23.05.2013 14:46, schrieb Matthew O'Connor: >> On 05/23/2013 06:24 AM, Smart Weblications GmbH - Florian Wiessner wrote: >>> node02:/ocfs2/usr/src/linux-3.4.46# cat drivers/net/bonding/bond_alb.c.rej >> My most sincere apologies - one more time, from a different mail server >> that hopefully won't go around changing my attachments. If this doesn't >> work I guess sendmail will be the next alternative. >> > > 3.4.47 got released without that included :-/?! > > https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.4.47 Things take time, I haven't worked on a networking -stable submission in a while, I'll get to it by the end of the wake. Be patient. -- 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: System slow down from udev
On Wed, May 29, 2013 at 02:30:12AM +0200, Rafael J. Wysocki wrote: > On Tuesday, May 28, 2013 05:01:41 PM Yinghai Lu wrote: > > On Tue, May 28, 2013 at 4:57 PM, Rafael J. Wysocki wrote: > > > On Tuesday, May 28, 2013 04:46:30 PM Yinghai Lu wrote: > > >> On Tue, May 28, 2013 at 4:50 PM, Rafael J. Wysocki wrote: > > >> > On Tuesday, May 28, 2013 04:39:37 PM Yinghai Lu wrote: > > >> >> Raphael: > > >> >> > > >> >> Found one commit in your linus-pm cause user space very slow... > > >> >> at least from udev start... > > >> > > > >> > I obviously can't reproduce it, so it would be great if you could give > > >> > me > > >> > more details. > > >> > > > >> > Is there anything unusual about your test system? > > >> > > >> they are normal nehalem ex, westmere ex and ivybridge ex 8 sockets > > >> system. > > > > > > Do all of them have the same problem? > > > > yes > > > > > > > > What distro is running there? > > > > Using rescue initrd/root disk from opensuse 11.4 (?) and boot from network. > > > > udevd version is 128. > > I'm successfully running kernels including that commit on two different boxes > (dual-core and quad-core, both Intel, the quad-core one is Sandy Bridge) with > OpenSUSE 12.2 and 12.3. > > There's a machine with an older OpenSUSE on it somewhere here, but I won't be > able to get to it before tomorrow evening. > > I have no idea what's wrong at the moment. > > Please attach your .config for comparison and maybe Greg will have an idea > about what's up with udev vs that commit (Greg, the > commit in question, unfortunately far from trivial, is > http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=acpi-hotplug&id=ac212b6980d8d5eda705864fc5a8ecddc6d6eacc). I don't see how this would "slow down" the boot process. Can someone run the bootchart tool on the machine to see where the delays are? 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: https://lkml.org/lkml/2013/2/1/531
Am 23.05.2013 14:46, schrieb Matthew O'Connor: > On 05/23/2013 06:24 AM, Smart Weblications GmbH - Florian Wiessner wrote: >> node02:/ocfs2/usr/src/linux-3.4.46# cat drivers/net/bonding/bond_alb.c.rej > My most sincere apologies - one more time, from a different mail server > that hopefully won't go around changing my attachments. If this doesn't > work I guess sendmail will be the next alternative. > 3.4.47 got released without that included :-/?! https://www.kernel.org/pub/linux/kernel/v3.x/ChangeLog-3.4.47 -- Mit freundlichen Grüßen, Florian Wiessner Smart Weblications GmbH Martinsberger Str. 1 D-95119 Naila fon.: +49 9282 9638 200 fax.: +49 9282 9638 205 24/7: +49 900 144 000 00 - 0,99 EUR/Min* http://www.smart-weblications.de -- Sitz der Gesellschaft: Naila Geschäftsführer: Florian Wiessner HRB-Nr.: HRB 3840 Amtsgericht Hof *aus dem dt. Festnetz, ggf. abweichende Preise aus dem Mobilfunknetz -- 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] ARM: Exynos fixes for 3.10-rc
Hi Linus, The following changes since commit f4ae176c626311d6507c9a2d263657c4cc4e1667: Merge tag 'sunxi-fixes-for-3.10' of git://github.com/mripard/linux into fixes (2013-05-24 15:50:28 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git tags/fixes-for-linus for you to fetch changes up to da9d0fbf5e9aa47492a19588bd0efd18d6d172e0: ARM: exynos: defconfig update (2013-05-28 17:21:41 -0700) ARM: Exynos fixes for 3.10-rc Here's a shorter set of fixes for 3.10, all for Samsung Exynos platforms. It also includes a defconfig update so that exynos_defconfig provides a meaningful set of drivers to boot an unmodified kernel on the Samsung ARM-based Chromebooks. Jungseok Lee (1): ARM: EXYNOS: fix software reset logic for EXYNOS5440 SOC Olof Johansson (2): Merge tag 'samsung-fixes-3' of git://git.kernel.org/.../kgene/linux-samsung into fixes ARM: exynos: defconfig update Tomasz Figa (2): ARM: EXYNOS: Fix support of Exynos4210 rev0 SoC ARM: SAMSUNG: Add names to fimd0 IRQ resources Vivek Gautam (1): ARM: dts: Enabling samsung-usb2phy driver for exynos5250 arch/arm/boot/dts/exynos5250.dtsi | 15 + arch/arm/configs/exynos_defconfig | 54 +- arch/arm/mach-exynos/Kconfig | 3 +- arch/arm/mach-exynos/common.c | 39 +++-- arch/arm/mach-exynos/common.h | 2 ++ arch/arm/mach-exynos/mach-universal_c210.c | 5 ++- arch/arm/plat-samsung/devs.c | 6 ++-- 7 files changed, 107 insertions(+), 17 deletions(-) -- 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] usb: omap2430: fix memleak in err case
On 2013/5/28 23:34, Andy Shevchenko wrote: > No go. > > Check the 4b7e450fb5cefb5865c77999a675330206ab3b8a > And update you tree, please. > > -- > With Best Regards, > Andy Shevchenko > > It had been changed :( Thanks, Libo -- 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] hwrng: use platform_{get,set}_drvdata()
Use the wrapper functions for getting and setting the driver data using
platform_device instead of using dev_{get,set}_drvdata() with &pdev->dev,
so we can directly pass a struct platform_device.
Also, unnecessary dev_set_drvdata() is removed, because the driver core
clears the driver data to NULL after device_release or on probe failure.
Signed-off-by: Jingoo Han
---
Changes since v1:
- re-based on the latest 'cryptodev' tree
drivers/char/hw_random/n2-drv.c |6 ++
drivers/char/hw_random/octeon-rng.c |4 ++--
drivers/char/hw_random/omap-rng.c |6 +++---
3 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/drivers/char/hw_random/n2-drv.c b/drivers/char/hw_random/n2-drv.c
index 20b962e..f9beed5 100644
--- a/drivers/char/hw_random/n2-drv.c
+++ b/drivers/char/hw_random/n2-drv.c
@@ -700,7 +700,7 @@ static int n2rng_probe(struct platform_device *op)
if (err)
goto out_free_units;
- dev_set_drvdata(&op->dev, np);
+ platform_set_drvdata(op, np);
schedule_delayed_work(&np->work, 0);
@@ -721,7 +721,7 @@ out:
static int n2rng_remove(struct platform_device *op)
{
- struct n2rng *np = dev_get_drvdata(&op->dev);
+ struct n2rng *np = platform_get_drvdata(op);
np->flags |= N2RNG_FLAG_SHUTDOWN;
@@ -736,8 +736,6 @@ static int n2rng_remove(struct platform_device *op)
kfree(np);
- dev_set_drvdata(&op->dev, NULL);
-
return 0;
}
diff --git a/drivers/char/hw_random/octeon-rng.c
b/drivers/char/hw_random/octeon-rng.c
index 1eada56..f2885db 100644
--- a/drivers/char/hw_random/octeon-rng.c
+++ b/drivers/char/hw_random/octeon-rng.c
@@ -96,7 +96,7 @@ static int octeon_rng_probe(struct platform_device *pdev)
rng->ops = ops;
- dev_set_drvdata(&pdev->dev, &rng->ops);
+ platform_set_drvdata(pdev, &rng->ops);
ret = hwrng_register(&rng->ops);
if (ret)
return -ENOENT;
@@ -108,7 +108,7 @@ static int octeon_rng_probe(struct platform_device *pdev)
static int __exit octeon_rng_remove(struct platform_device *pdev)
{
- struct hwrng *rng = dev_get_drvdata(&pdev->dev);
+ struct hwrng *rng = platform_get_drvdata(pdev);
hwrng_unregister(rng);
diff --git a/drivers/char/hw_random/omap-rng.c
b/drivers/char/hw_random/omap-rng.c
index 749dc16..e5deb99 100644
--- a/drivers/char/hw_random/omap-rng.c
+++ b/drivers/char/hw_random/omap-rng.c
@@ -116,7 +116,7 @@ static int omap_rng_probe(struct platform_device *pdev)
};
omap_rng_ops.priv = (unsigned long)priv;
- dev_set_drvdata(&pdev->dev, priv);
+ platform_set_drvdata(pdev, priv);
priv->mem_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!priv->mem_res) {
@@ -129,7 +129,7 @@ static int omap_rng_probe(struct platform_device *pdev)
ret = PTR_ERR(priv->base);
goto err_ioremap;
}
- dev_set_drvdata(&pdev->dev, priv);
+ platform_set_drvdata(pdev, priv);
pm_runtime_enable(&pdev->dev);
pm_runtime_get_sync(&pdev->dev);
@@ -156,7 +156,7 @@ err_ioremap:
static int __exit omap_rng_remove(struct platform_device *pdev)
{
- struct omap_rng_private_data *priv = dev_get_drvdata(&pdev->dev);
+ struct omap_rng_private_data *priv = platform_get_drvdata(pdev);
hwrng_unregister(&omap_rng_ops);
--
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: [RFC] Add co-maintainer for fbdev
On 23:19 Tue 28 May , Arnd Bergmann wrote: > On Monday 27 May 2013, Florian Tobias Schandinat wrote: > > >> On Fri, May 24, 2013 at 8:38 AM, Jean-Christophe PLAGNIOL-VILLARD > > >> wrote: > > >>> Hi Florian, > > >>> > > >>> As you seems very busy I'd like to propose the help you to > > >>> handle the > > >>> fbdev subsystem to easier the rich of the fbdev patch to Linus > > >>> > > >>> As I'm working on fbdev on at91 and others and already > > >>> Co-Maintain the > > >>> at91 mach on ARM > > >>> > > >>> And if you are not willing to continue I could take over > > > > Yeah, it would be great if you could help, at the moment I get barely > > any sleep, let alone that I could keep up with the majority of mail I > > get. I'll let you decide whether you want to be sole maintainer or not. > > For any bigger subsystems, it's good practice to have two maintainers, > even if one of them does all the work. I think it makes sense to have > Jean-Christophe as the primary maintainer and owner of the git tree, > but it may also be good to have you or Tomi listed as a second maintainer > for times when Jean-Christophe isn't available. I agree with Arnd As example I'll be mostly off first week of June. Tomi Florian what do you think I plan to send the patch + PULL to Linus end of this week before I work-off For the record the new git tree is here git://git.kernel.org/pub/scm/linux/kernel/git/plagnioj/linux-fbdev.git Best Regrds, J. -- 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: [RFC PATCH v1 0/5] BTRFS hot relocation support
On Tue, May 21, 2013 at 02:22:34AM +, Duncan wrote: > zwu.kernel posted on Mon, 20 May 2013 23:11:22 +0800 as excerpted: > > > The patchset is trying to introduce hot relocation support > > for BTRFS. In hybrid storage environment, when the data in rotating disk > > get hot, it can be relocated to nonrotating disk by BTRFS hot relocation > > support automatically; also, if nonrotating disk ratio exceed its upper > > threshold, the data which get cold can be looked up and relocated to > > rotating disk to make more space in nonrotating disk at first, and then > > the data which get hot will be relocated to nonrotating disk > > automatically. > > One advantage of a filesystem implementation, as opposed to bcache or > dmcache, is arguably a corner-case, but it's /my/ corner-case, so... > > I run an intr*-less (I guess technically, empty initramfs) monolithic- > kernel boot, using the kernel commandline root= and (formerly) md= and > related logic to choose/assemble/mount root directly from the kernel > command line via bootloader (grub2). Thus, any user-space-required-to- > mount-root is out, since I don't have an initr* and thus no early > userspace. That means both lvm2 and dmcache (AFAIK) are out. I'm not > sure about bcache, but it has other negatives, particularly against btrfs- > raid-1 and I'd guess md/raid-1 as well. > > Much like md before it, btrfs, while normally requiring the user-space- > required device-scan to properly handle multiple devices, has kernel- > command-line options that allow direct kernel multi-device assembly > without the help of early-userspace/initr*. I wouldn't be averse to adding such functionality to bcache, provided it could be done reasonably cleanly/sensibly. It's not high on my list but I'd accept patches :) -- 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/
cpu hotplug broken in linux-next
If I boot with: maxcpus=2 possible_cpus=4 I get # grep . /sys/devices/system/cpu/cpu[0-9]*/online' /sys/devices/system/cpu/cpu1/online:1 /sys/devices/system/cpu/cpu2/online:1 /sys/devices/system/cpu/cpu3/online:1 When 2 and 3 *should* be offline. I also get -EINVAL if I try to re-offline them in this state. 2 and 3 don't show up in /proc/cpuinfo, so sysfs just looks broken here. I'm bisecting it at the moment, but won't get to finish until tomorrow. Just thought I'd report early and often. :) -- 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] rcu: fix a race in hlist_nulls_for_each_entry_rcu macro
On Tue, 2013-05-28 at 13:10 +0400, Roman Gushchin wrote: > On 28.05.2013 04:12, Eric Dumazet wrote: > > Adding a barrier() is probably what we want. > > I agree, inserting barrier() is also a correct and working fix. Yeah, but I can not find a clean way to put it inside the "for (;;)" for (barrier();;) -> error: expected expression before ‘__asm__’ No user currently does : if (condition) hlist_nulls_for_each_entry_rcu(tpos, pos, head, member) But who knows... -- 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: System slow down from udev
On Tuesday, May 28, 2013 05:01:41 PM Yinghai Lu wrote: > On Tue, May 28, 2013 at 4:57 PM, Rafael J. Wysocki wrote: > > On Tuesday, May 28, 2013 04:46:30 PM Yinghai Lu wrote: > >> On Tue, May 28, 2013 at 4:50 PM, Rafael J. Wysocki wrote: > >> > On Tuesday, May 28, 2013 04:39:37 PM Yinghai Lu wrote: > >> >> Raphael: > >> >> > >> >> Found one commit in your linus-pm cause user space very slow... > >> >> at least from udev start... > >> > > >> > I obviously can't reproduce it, so it would be great if you could give me > >> > more details. > >> > > >> > Is there anything unusual about your test system? > >> > >> they are normal nehalem ex, westmere ex and ivybridge ex 8 sockets system. > > > > Do all of them have the same problem? > > yes > > > > > What distro is running there? > > Using rescue initrd/root disk from opensuse 11.4 (?) and boot from network. > > udevd version is 128. I'm successfully running kernels including that commit on two different boxes (dual-core and quad-core, both Intel, the quad-core one is Sandy Bridge) with OpenSUSE 12.2 and 12.3. There's a machine with an older OpenSUSE on it somewhere here, but I won't be able to get to it before tomorrow evening. I have no idea what's wrong at the moment. Please attach your .config for comparison and maybe Greg will have an idea about what's up with udev vs that commit (Greg, the commit in question, unfortunately far from trivial, is http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=acpi-hotplug&id=ac212b6980d8d5eda705864fc5a8ecddc6d6eacc). Thanks, Rafael -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- 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] KVM: PPC: Add support for IOMMU in-kernel handling
On 05/29/2013 02:32 AM, Scott Wood wrote: > On 05/24/2013 09:45:24 PM, David Gibson wrote: >> On Wed, May 22, 2013 at 04:06:57PM -0500, Scott Wood wrote: >> > On 05/20/2013 10:06:46 PM, Alexey Kardashevskiy wrote: >> > >diff --git a/arch/powerpc/kvm/powerpc.c b/arch/powerpc/kvm/powerpc.c >> > >index 8465c2a..da6bf61 100644 >> > >--- a/arch/powerpc/kvm/powerpc.c >> > >@@ -396,6 +396,7 @@ int kvm_dev_ioctl_check_extension(long ext) >> > >+++ b/arch/powerpc/kvm/powerpc.c >> > > break; >> > > #endif >> > > case KVM_CAP_SPAPR_MULTITCE: >> > >+case KVM_CAP_SPAPR_TCE_IOMMU: >> > > r = 1; >> > > break; >> > > default: >> > >> > Don't advertise SPAPR capabilities if it's not book3s -- and >> > probably there's some additional limitation that would be >> > appropriate. >> >> So, in the case of MULTITCE, that's not quite right. PR KVM can >> emulate a PAPR system on a BookE machine, and there's no reason not to >> allow TCE acceleration as well. > > That might (or might not; consider things like Altivec versus SPE opcode > conflict, whether unimplemented SPRs trap, behavior of unprivileged > SPRs/instructions, etc) be true in theory, but it's not currently a > supported configuration. BookE KVM does not support emulating a different > CPU than the host. In the unlikely case that ever changes to the point of > allowing PAPR guests on a BookE host, then we can revisit how to properly > determine whether the capability is supported, but for now the capability > will never be valid in the CONFIG_BOOKE case (though I'd rather see it > depend on an appropriate book3s symbol than depend on !BOOKE). > > Or we could just leave it as is, and let it indicate whether the host > kernel supports the feature in general, with the user needing to understand > when it's applicable... I'm a bit confused by the documentation, however > -- the MULTITCE capability was documented in the "capabilities that can be > enabled" section, but I don't see where it can be enabled. True, it cannot be enabled (but it could be enabled a long time ago), it is either supported or not, I'll fix the documentation. Thanks! -- Alexey -- 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] md: bcache: io.c: fix a potential NULL pointer dereference
On Tue, May 28, 2013 at 12:31:15AM -0700, Kumar Amit Mehta wrote: > bio_alloc_bioset returns NULL on failure. This fix adds a missing check > for potential NULL pointer dereferencing. Whoops, that's definitely a bug. Thanks, applied. How'd you find it? -- 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: Stupid VFS name lookup interface..
On Sun, 26 May 2013 08:02:51 -0400, "Theodore Ts'o" said: > Have any of the arguments over the proper security models changed over > or have gotten resolved over the past six years, while I haven't been > looking? Doubtful, because the security models are addressing different threat models. If you can't agree on what you're trying to secure against, there can be no agreement on how to do the securing. pgpZTTuqxxtRr.pgp Description: PGP signature
Re: [PATCH 1/3] x86: increase precision of x86_platform.get/set_wallclock()
On 05/13/2013 10:56 AM, David Vrabel wrote: From: David Vrabel All the virtualized platforms (KVM, lguest and Xen) have persistent wallclocks that have more than one second of precision. read_persistent_wallclock() and update_persistent_wallclock() allow for nanosecond precision but their implementation on x86 with x86_platform.get/set_wallclock() only allows for one second precision. This means guests may see a wallclock time that is off by up to 1 second. Make set_wallclock() and get_wallclock() take a struct timespec parameter (which allows for nanosecond precision) so KVM and Xen guests may start with a more accurate wallclock time and a Xen dom0 can maintain a more accurate wallclock for guests. Signed-off-by: David Vrabel --- arch/x86/include/asm/mc146818rtc.h |4 ++-- arch/x86/include/asm/x86_init.h|6 -- arch/x86/kernel/kvmclock.c |9 +++-- arch/x86/kernel/rtc.c | 17 +++-- arch/x86/lguest/boot.c |4 ++-- arch/x86/platform/efi/efi.c| 10 ++ arch/x86/xen/time.c| 19 ++- include/linux/efi.h|4 ++-- Just FYI, David: You missed the vrtc code with this conversion. I finally got around to pushing my current queue to my public tree and the kbuild robot noticed the build failure (required INTEL_MID config to trigger). The fix I've queued is here: https://git.linaro.org/gitweb?p=people/jstultz/linux.git;a=commitdiff;h=52d8e9cc6718ae9e6c44b7723028e4717ba91c8b;hp=1dd5234774b33a17743ae62e8b46b5cd0059e1c7 Let me know if you have any objection or comments on this. thanks -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/
