[PULL 00/10] NBD updates for 4.3
Hi Jens, I hope this is not too late. Here are some NBD updates. The most interesting one is probably the first patch, which improves the timeout detection of NBD. The timout covers now the last reaction of the server. If there are open requests and we don't receive anything from the server within the timeout, the connection is killed. The rest of the patches are smaller cleanups and some new debugfs entries about the internal state of NBD. Best Regards, Markus The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754: Linux 4.2-rc1 (2015-07-05 11:01:52 -0700) are available in the git repository at: git://git.pengutronix.de/git/mpa/linux-nbd.git tags/nbd-for-4.3 for you to fetch changes up to 9bdcdf81aca98816fae86c724855e263454010f0: nbd: flags is a u32 variable (2015-08-17 08:08:50 +0200) NBD updates for 4.3 Markus Pargmann (10): nbd: Fix timeout detection nbd: sock_shutdown, remove conditional lock nbd: restructure sock_shutdown nbd: Remove 'harderror' and propagate error properly nbd: Move clear queue debug message nbd: Remove variable 'pid' nbd: Add debugfs entries nbd: Change 'disconnect' to be boolean nbd: Rename functions for clearness of recv/send path nbd: flags is a u32 variable drivers/block/nbd.c | 362 +--- 1 file changed, 290 insertions(+), 72 deletions(-) -- 2.4.6 -- 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 09/10] nbd: Rename functions for clearness of recv/send path
This patch renames functions so that it is clear what the function does.
Otherwise it is not directly understandable what for example 'do_it' means.
Signed-off-by: Markus Pargmann
---
drivers/block/nbd.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 44160a9e493e..9862c3e64ff2 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -399,7 +399,7 @@ static struct device_attribute pid_attr = {
.show = pid_show,
};
-static int nbd_do_it(struct nbd_device *nbd)
+static int nbd_thread_recv(struct nbd_device *nbd)
{
struct request *req;
int ret;
@@ -530,7 +530,7 @@ error_out:
nbd_end_request(nbd, req);
}
-static int nbd_thread(void *data)
+static int nbd_thread_send(void *data)
{
struct nbd_device *nbd = data;
struct request *req;
@@ -584,7 +584,7 @@ static int nbd_thread(void *data)
* { printk( "Warning: Ignoring result!\n"); nbd_end_request( req ); }
*/
-static void do_nbd_request(struct request_queue *q)
+static void nbd_request_handler(struct request_queue *q)
__releases(q->queue_lock) __acquires(q->queue_lock)
{
struct request *req;
@@ -738,7 +738,7 @@ static int __nbd_ioctl(struct block_device *bdev, struct
nbd_device *nbd,
else
blk_queue_flush(nbd->disk->queue, 0);
- thread = kthread_run(nbd_thread, nbd, "%s",
+ thread = kthread_run(nbd_thread_send, nbd, "%s",
nbd_name(nbd));
if (IS_ERR(thread)) {
mutex_lock(>tx_lock);
@@ -746,7 +746,7 @@ static int __nbd_ioctl(struct block_device *bdev, struct
nbd_device *nbd,
}
nbd_dev_dbg_init(nbd);
- error = nbd_do_it(nbd);
+ error = nbd_thread_recv(nbd);
nbd_dev_dbg_close(nbd);
kthread_stop(thread);
@@ -1021,7 +1021,7 @@ static int __init nbd_init(void)
* every gendisk to have its very own request_queue struct.
* These structs are big so we dynamically allocate them.
*/
- disk->queue = blk_init_queue(do_nbd_request, _lock);
+ disk->queue = blk_init_queue(nbd_request_handler, _lock);
if (!disk->queue) {
put_disk(disk);
goto out;
--
2.4.6
--
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 10/10] nbd: flags is a u32 variable
The flags variable is used as u32 variable. This patch changes the type
to be u32.
Signed-off-by: Markus Pargmann
---
drivers/block/nbd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 9862c3e64ff2..1176a3b27a7e 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -41,7 +41,7 @@
#include
struct nbd_device {
- int flags;
+ u32 flags;
struct socket * sock; /* If == NULL, device is not ready, yet */
int magic;
--
2.4.6
--
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 04/10] nbd: Remove 'harderror' and propagate error properly
Instead of a variable 'harderror' we can simply try to correctly
propagate errors to the userspace.
This patch removes the harderror variable and passes errors through
error pointers and nbd_do_it back to the userspace.
Signed-off-by: Markus Pargmann
Acked-by: Pavel Machek
---
drivers/block/nbd.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/block/nbd.c b/drivers/block/nbd.c
index 2c3661e4d364..8bce05d0df5e 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -41,7 +41,6 @@
struct nbd_device {
int flags;
- int harderror; /* Code of hard error */
struct socket * sock; /* If == NULL, device is not ready, yet */
int magic;
@@ -329,26 +328,24 @@ static struct request *nbd_read_stat(struct nbd_device
*nbd)
if (result <= 0) {
dev_err(disk_to_dev(nbd->disk),
"Receive control failed (result %d)\n", result);
- goto harderror;
+ return ERR_PTR(result);
}
if (ntohl(reply.magic) != NBD_REPLY_MAGIC) {
dev_err(disk_to_dev(nbd->disk), "Wrong magic (0x%lx)\n",
(unsigned long)ntohl(reply.magic));
- result = -EPROTO;
- goto harderror;
+ return ERR_PTR(-EPROTO);
}
req = nbd_find_request(nbd, *(struct request **)reply.handle);
if (IS_ERR(req)) {
result = PTR_ERR(req);
if (result != -ENOENT)
- goto harderror;
+ return ERR_PTR(result);
dev_err(disk_to_dev(nbd->disk), "Unexpected reply (%p)\n",
reply.handle);
- result = -EBADR;
- goto harderror;
+ return ERR_PTR(-EBADR);
}
if (ntohl(reply.error)) {
@@ -376,9 +373,6 @@ static struct request *nbd_read_stat(struct nbd_device *nbd)
}
}
return req;
-harderror:
- nbd->harderror = result;
- return NULL;
}
static ssize_t pid_show(struct device *dev,
@@ -413,8 +407,15 @@ static int nbd_do_it(struct nbd_device *nbd)
nbd->task_recv = current;
- while ((req = nbd_read_stat(nbd)) != NULL)
+ while (1) {
+ req = nbd_read_stat(nbd);
+ if (IS_ERR(req)) {
+ ret = PTR_ERR(req);
+ break;
+ }
+
nbd_end_request(nbd, req);
+ }
nbd->task_recv = NULL;
@@ -734,8 +735,7 @@ static int __nbd_ioctl(struct block_device *bdev, struct
nbd_device *nbd,
kthread_stop(thread);
mutex_lock(>tx_lock);
- if (error)
- return error;
+
sock_shutdown(nbd);
sock = nbd->sock;
nbd->sock = NULL;
@@ -754,7 +754,7 @@ static int __nbd_ioctl(struct block_device *bdev, struct
nbd_device *nbd,
blkdev_reread_part(bdev);
if (nbd->disconnect) /* user requested, ignore socket errors */
return 0;
- return nbd->harderror;
+ return error;
}
case NBD_CLEAR_QUE:
--
2.4.6
--
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] memory-barriers: remove smp_mb__after_unlock_lock()
On Mon, Aug 17, 2015 at 02:06:07PM +1000, Michael Ellerman wrote: > On Wed, 2015-08-12 at 08:43 -0700, Paul E. McKenney wrote: > > On Wed, Aug 12, 2015 at 02:44:15PM +0100, Will Deacon wrote: > > > Hello Paul, > > > > > > On Fri, Jul 24, 2015 at 04:30:46PM +0100, Paul E. McKenney wrote: > > > > On Fri, Jul 24, 2015 at 12:31:01PM +0100, Will Deacon wrote: > > > > > On Wed, Jul 15, 2015 at 02:12:21PM +0100, Paul E. McKenney wrote: > > > > > > > > commit 695c05d4b9666c50b40a1c022678b5f6e2e3e771 > > > > > > > > Author: Paul E. McKenney > > > > > > > > Date: Tue Jul 14 18:35:23 2015 -0700 > > > > > > > > > > > > > > > > rcu,locking: Privatize smp_mb__after_unlock_lock() > > > > > > > > > > > > > > > > RCU is the only thing that uses > > > > > > > > smp_mb__after_unlock_lock(), and is > > > > > > > > likely the only thing that ever will use it, so this commit > > > > > > > > makes this > > > > > > > > macro private to RCU. > > > > > > > > > > > > > > > > Signed-off-by: Paul E. McKenney > > > > > > > > Cc: Will Deacon > > > > > > > > Cc: Peter Zijlstra > > > > > > > > Cc: Benjamin Herrenschmidt > > > > > > > > Cc: "linux-a...@vger.kernel.org" > > > > > > > > > > > > > > > > > > Are you planning to queue this somewhere? I think it makes sense > > > > > regardless > > > > > of whether we change PowerPc or not and ideally it would be merged > > > > > around > > > > > the same time as my relaxed atomics series. > > > > > > > > I have is in -rcu. By default, I will push it to the 4.4 merge window. > > > > Please let me know if you need it sooner. > > > > > > The generic relaxed atomics are now queued in -tip, so it would be really > > > good to see this Documentation update land in 4.3 if at all possible. I > > > appreciate it's late in the cycle, but it's always worth asking. > > > > Can't hurt to give it a try. I have set -rcu's rcu/next branch to this > > commit, and if it passes a few day's worth of testing, I will see what > > Ingo has to say about a pull request. > > > > This commit also privatizes smp_mb__after_unlock_lock() as well as > > updating documentation. Looks like we need to strengthen powerpc's > > locking primitives, then get rid of smp_mb__after_unlock_lock() entirely. > > Or did that already happen and I just missed it? > > No it didn't. > > I thought the end result of this thread was that we didn't *need* to change > the > powerpc lock semantics? Or did I read it wrong? > > ie. the docs now say that RELEASE+ACQUIRE is not a full barrier, which is > consistent with our current implementation. That change happened about 1.5 years ago, and I thought that the current discussion was about reversing it, based in part on the recent powerpc benchmarks of locking primitives with and without the sync instruction. But regardless, I clearly cannot remove either the smp_mb__after_unlock_lock() or the powerpc definition of it to be smp_mb() if powerpc unlock/lock is not strengthened. 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: [RFC v2 1/4] ftrace: allow arch-specific check_stack()
Will,
On 08/12/2015 02:03 AM, Will Deacon wrote:
On Tue, Aug 04, 2015 at 08:44:06AM +0100, AKASHI Takahiro wrote:
A stack frame pointer may be used in a different way depending on
cpu architecture. Thus it is not always appropriate to slurp the stack
contents, as currently done in check_stack(), in order to calcurate
a stack index (height) at a given function call. At least not on arm64.
This patch extract potentially arch-specific code from check_stack()
and puts it into a new arch_check_stack(), which is declared as weak.
So we will be able to add arch-specific and most efficient way of
stack traversing Later.
Signed-off-by: AKASHI Takahiro
If arm64 is the only architecture behaving differently, then I'm happy
to reconsider the fix to unwind_frame that we merged in e306dfd06fcb
("ARM64: unwind: Fix PC calculation"). I'd have thought any architecture
with a branch-and-link instruction would potentially have the same issue,
so we could just be fixing things in the wrong place if ftrace works
everywhere else.
I'm not the right person to answer for other architectures (and ftrace
behavior on them.) The only thing I know is that current ftrace stack tracer
works correctly only if the addresses stored and found on stack match to
the ones returned by save_stack_trace().
Anyway, the fix above is not the only reason that I want to introduce
arch-specific
arch_check_stack(). Other issues to fix include
- combined case of stack tracer and function graph tracer (common across
arch's)
- exception entries (as I'm trying to address in RFC 4/4)
- in-accurate stack size (for each function, my current fix is not perfect
though.)
Thanks,
-Takahiro AKASHI
Will
--
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 failure after merge of the security tree
Hi all, On Mon, 17 Aug 2015 15:29:53 +1000 Stephen Rothwell wrote: > > After a bit of digging, I installed libssl-dev on my Debian build > machines. Is this worth a mention in Documentation/Changes along with all the other prerequisites? -- Cheers, Stephen Rothwells...@canb.auug.org.au -- 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/3] Introduce usb charger framework to deal with the usb gadget power negotation
On 17 August 2015 at 09:15, Li Jun wrote: > On Fri, Aug 14, 2015 at 07:04:56PM +0800, Baolin Wang wrote: >> On 14 August 2015 at 16:55, Li Jun wrote: >> > Hi Baolin, >> > >> > On Fri, Aug 14, 2015 at 05:47:43PM +0800, Baolin Wang wrote: >> >> Currently the Linux kernel does not provide any standard integration of >> >> this >> >> feature that integrates the USB subsystem with the system power regulation >> >> provided by PMICs meaning that either vendors must add this in their >> >> kernels >> >> or USB gadget devices based on Linux (such as mobile phones) may not >> >> behave >> >> as they should. >> >> >> >> Providing a standard framework for doing this in the kernel. >> >> >> > >> > Why not add power supply class support into this? >> > >> >> Hi Jun, >> >> We don't need the power supply class support into the usb charger, > I suppose usb charger is also a power supply for the system, we can use power > supply class framework for notify mechanism and get/set many attributes(maybe > also the current limit), I see those usb charger drivers under ./driver/power/ > are designed with power supply supported. > I don't think so. The usb charger is rely on the usb gadget, which is not a complete power supply device and it combines the usb and the power supply. Thus we make it into usb gadget system. Thanks. > Li Jun >> just introduce the notify mechanism for power to set the current limit >> when notifying some events from usb charger. Maybe I misunderstand >> your meanings, please describe it detailedly. Thanks for your >> comments. >> >> > Li Jun >> > >> >> >> >> -- >> Baolin.wang >> Best Regards -- Baolin.wang Best Regards -- 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/
[v1 6/6] NET: nps_enet: minor namespace cleanup
From: Noam Camus
We define buf_int_enable in the minimal namespace it is used.
Signed-off-by: Noam Camus
---
drivers/net/ethernet/ezchip/nps_enet.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/ezchip/nps_enet.c
b/drivers/net/ethernet/ezchip/nps_enet.c
index de4aafd..3ba9be4 100644
--- a/drivers/net/ethernet/ezchip/nps_enet.c
+++ b/drivers/net/ethernet/ezchip/nps_enet.c
@@ -179,14 +179,15 @@ static int nps_enet_poll(struct napi_struct *napi, int
budget)
{
struct net_device *ndev = napi->dev;
struct nps_enet_priv *priv = netdev_priv(ndev);
- struct nps_enet_buf_int_enable buf_int_enable;
u32 work_done;
- buf_int_enable.rx_rdy = NPS_ENET_ENABLE;
- buf_int_enable.tx_done = NPS_ENET_ENABLE;
work_done = nps_enet_rx_handler(ndev);
if (work_done < budget) {
+ struct nps_enet_buf_int_enable buf_int_enable;
+
napi_complete(napi);
+ buf_int_enable.rx_rdy = NPS_ENET_ENABLE;
+ buf_int_enable.tx_done = NPS_ENET_ENABLE;
nps_enet_reg_set(priv, NPS_ENET_REG_BUF_INT_ENABLE,
buf_int_enable.value);
}
--
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/
[v1 5/6] NET: nps_enet: TX done acknowledge.
From: Noam Camus
This is needed for when TX done interrupt is in
"level mode".
For example it is true for some simulators of this device.
Signed-off-by: Noam Camus
---
drivers/net/ethernet/ezchip/nps_enet.c |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/drivers/net/ethernet/ezchip/nps_enet.c
b/drivers/net/ethernet/ezchip/nps_enet.c
index 0c13015..de4aafd 100644
--- a/drivers/net/ethernet/ezchip/nps_enet.c
+++ b/drivers/net/ethernet/ezchip/nps_enet.c
@@ -150,6 +150,9 @@ static void nps_enet_tx_handler(struct net_device *ndev)
if (!priv->tx_packet_sent || tx_ctrl.ct)
return;
+ /* Ack Tx ctrl register */
+ nps_enet_reg_set(priv, NPS_ENET_REG_TX_CTL, 0);
+
/* Check Tx transmit error */
if (unlikely(tx_ctrl.et)) {
ndev->stats.tx_errors++;
--
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/
[v1 4/6] NET: nps_enet: drop control frames
From: Noam Camus
We set controller to drop control frames and not trying
to pass them on. This is only needed for debug reasons.
Signed-off-by: Noam Camus
---
drivers/net/ethernet/ezchip/nps_enet.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/ezchip/nps_enet.c
b/drivers/net/ethernet/ezchip/nps_enet.c
index f78ad3d..0c13015 100644
--- a/drivers/net/ethernet/ezchip/nps_enet.c
+++ b/drivers/net/ethernet/ezchip/nps_enet.c
@@ -307,11 +307,8 @@ static void nps_enet_hw_enable_control(struct net_device
*ndev)
/* Discard Packets bigger than max frame length */
max_frame_length = ETH_HLEN + ndev->mtu + ETH_FCS_LEN;
- if (max_frame_length <= NPS_ENET_MAX_FRAME_LENGTH) {
+ if (max_frame_length <= NPS_ENET_MAX_FRAME_LENGTH)
ge_mac_cfg_3->max_len = max_frame_length;
- nps_enet_reg_set(priv, NPS_ENET_REG_GE_MAC_CFG_3,
-ge_mac_cfg_3->value);
- }
/* Enable interrupts */
buf_int_enable.rx_rdy = NPS_ENET_ENABLE;
@@ -339,11 +336,14 @@ static void nps_enet_hw_enable_control(struct net_device
*ndev)
ge_mac_cfg_0.tx_fc_en = NPS_ENET_ENABLE;
ge_mac_cfg_0.rx_fc_en = NPS_ENET_ENABLE;
ge_mac_cfg_0.tx_fc_retr = NPS_ENET_GE_MAC_CFG_0_TX_FC_RETR;
+ ge_mac_cfg_3->cf_drop = NPS_ENET_ENABLE;
/* Enable Rx and Tx */
ge_mac_cfg_0.rx_en = NPS_ENET_ENABLE;
ge_mac_cfg_0.tx_en = NPS_ENET_ENABLE;
+ nps_enet_reg_set(priv, NPS_ENET_REG_GE_MAC_CFG_3,
+ge_mac_cfg_3->value);
nps_enet_reg_set(priv, NPS_ENET_REG_GE_MAC_CFG_0,
ge_mac_cfg_0.value);
}
--
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/
[v1 3/6] NET: nps_enet: TX done race condition
From: Noam Camus
We need to set tx_skb pointer before send frame.
If we receive interrupt before we set pointer we will try
to free SKB with wrong pointer.
Now we are sure that SKB pointer will never be NULL during
handling TX done and check is removed.
Signed-off-by: Noam Camus
---
drivers/net/ethernet/ezchip/nps_enet.c | 10 +++---
1 files changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/ezchip/nps_enet.c
b/drivers/net/ethernet/ezchip/nps_enet.c
index af72181..f78ad3d 100644
--- a/drivers/net/ethernet/ezchip/nps_enet.c
+++ b/drivers/net/ethernet/ezchip/nps_enet.c
@@ -158,11 +158,7 @@ static void nps_enet_tx_handler(struct net_device *ndev)
ndev->stats.tx_bytes += tx_ctrl.nt;
}
- if (priv->tx_skb) {
- dev_kfree_skb_irq(priv->tx_skb);
- priv->tx_skb = NULL;
- }
-
+ dev_kfree_skb_irq(priv->tx_skb);
priv->tx_packet_sent = false;
if (netif_queue_stopped(ndev))
@@ -531,10 +527,10 @@ static netdev_tx_t nps_enet_start_xmit(struct sk_buff
*skb,
/* This driver handles one frame at a time */
netif_stop_queue(ndev);
- nps_enet_send_frame(ndev, skb);
-
priv->tx_skb = skb;
+ nps_enet_send_frame(ndev, skb);
+
return NETDEV_TX_OK;
}
--
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/
[v1 1/6] NET: nps_enet: replace use of cause register
From: Noam Camus
When interrupt is received we read directly from control
register for RX/TX instead of reading cause register
since this register fails to indicate TX done when
TX interrupt is "edge mode".
Signed-off-by: Noam Camus
---
drivers/net/ethernet/ezchip/nps_enet.c |9 +
drivers/net/ethernet/ezchip/nps_enet.h | 20
2 files changed, 5 insertions(+), 24 deletions(-)
diff --git a/drivers/net/ethernet/ezchip/nps_enet.c
b/drivers/net/ethernet/ezchip/nps_enet.c
index 24a85b2..0e652b4 100644
--- a/drivers/net/ethernet/ezchip/nps_enet.c
+++ b/drivers/net/ethernet/ezchip/nps_enet.c
@@ -211,12 +211,13 @@ static irqreturn_t nps_enet_irq_handler(s32 irq, void
*dev_instance)
{
struct net_device *ndev = dev_instance;
struct nps_enet_priv *priv = netdev_priv(ndev);
- struct nps_enet_buf_int_cause buf_int_cause;
+ struct nps_enet_rx_ctl rx_ctrl;
+ struct nps_enet_tx_ctl tx_ctrl;
- buf_int_cause.value =
- nps_enet_reg_get(priv, NPS_ENET_REG_BUF_INT_CAUSE);
+ rx_ctrl.value = nps_enet_reg_get(priv, NPS_ENET_REG_RX_CTL);
+ tx_ctrl.value = nps_enet_reg_get(priv, NPS_ENET_REG_TX_CTL);
- if (buf_int_cause.tx_done || buf_int_cause.rx_rdy)
+ if ((!tx_ctrl.ct && priv->tx_packet_sent) || rx_ctrl.cr)
if (likely(napi_schedule_prep(>napi))) {
nps_enet_reg_set(priv, NPS_ENET_REG_BUF_INT_ENABLE, 0);
__napi_schedule(>napi);
diff --git a/drivers/net/ethernet/ezchip/nps_enet.h
b/drivers/net/ethernet/ezchip/nps_enet.h
index fc45c9d..6703674 100644
--- a/drivers/net/ethernet/ezchip/nps_enet.h
+++ b/drivers/net/ethernet/ezchip/nps_enet.h
@@ -36,7 +36,6 @@
#define NPS_ENET_REG_RX_CTL0x810
#define NPS_ENET_REG_RX_BUF0x818
#define NPS_ENET_REG_BUF_INT_ENABLE0x8C0
-#define NPS_ENET_REG_BUF_INT_CAUSE 0x8C4
#define NPS_ENET_REG_GE_MAC_CFG_0 0x1000
#define NPS_ENET_REG_GE_MAC_CFG_1 0x1004
#define NPS_ENET_REG_GE_MAC_CFG_2 0x1008
@@ -108,25 +107,6 @@ struct nps_enet_buf_int_enable {
};
};
-/* Interrupt cause for data buffer events register */
-struct nps_enet_buf_int_cause {
- union {
- /* tx_done: Interrupt in the case when current frame was
-* read from TX buffer.
-* rx_rdy: Interrupt in the case when new frame is ready
-* in RX buffer.
-*/
- struct {
- u32
- __reserved:30,
- tx_done:1,
- rx_rdy:1;
- };
-
- u32 value;
- };
-};
-
/* Gbps Eth MAC Configuration 0 register */
struct nps_enet_ge_mac_cfg_0 {
union {
--
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/
[v1 2/6] NET: nps_enet: reduce processing latency.
From: Noam Camus
TX handler is minimalistic and there is no need to schedule
a NAPI job.
Tx done will be processed during hardware interrupt context.
Signed-off-by: Noam Camus
---
drivers/net/ethernet/ezchip/nps_enet.c | 17 ++---
1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/net/ethernet/ezchip/nps_enet.c
b/drivers/net/ethernet/ezchip/nps_enet.c
index 0e652b4..af72181 100644
--- a/drivers/net/ethernet/ezchip/nps_enet.c
+++ b/drivers/net/ethernet/ezchip/nps_enet.c
@@ -159,7 +159,7 @@ static void nps_enet_tx_handler(struct net_device *ndev)
}
if (priv->tx_skb) {
- dev_kfree_skb(priv->tx_skb);
+ dev_kfree_skb_irq(priv->tx_skb);
priv->tx_skb = NULL;
}
@@ -185,7 +185,6 @@ static int nps_enet_poll(struct napi_struct *napi, int
budget)
buf_int_enable.rx_rdy = NPS_ENET_ENABLE;
buf_int_enable.tx_done = NPS_ENET_ENABLE;
- nps_enet_tx_handler(ndev);
work_done = nps_enet_rx_handler(ndev);
if (work_done < budget) {
napi_complete(napi);
@@ -212,14 +211,18 @@ static irqreturn_t nps_enet_irq_handler(s32 irq, void
*dev_instance)
struct net_device *ndev = dev_instance;
struct nps_enet_priv *priv = netdev_priv(ndev);
struct nps_enet_rx_ctl rx_ctrl;
- struct nps_enet_tx_ctl tx_ctrl;
- rx_ctrl.value = nps_enet_reg_get(priv, NPS_ENET_REG_RX_CTL);
- tx_ctrl.value = nps_enet_reg_get(priv, NPS_ENET_REG_TX_CTL);
+ nps_enet_tx_handler(ndev);
- if ((!tx_ctrl.ct && priv->tx_packet_sent) || rx_ctrl.cr)
+ rx_ctrl.value = nps_enet_reg_get(priv, NPS_ENET_REG_RX_CTL);
+ if (rx_ctrl.cr)
if (likely(napi_schedule_prep(>napi))) {
- nps_enet_reg_set(priv, NPS_ENET_REG_BUF_INT_ENABLE, 0);
+ struct nps_enet_buf_int_enable buf_int_enable;
+
+ buf_int_enable.rx_rdy = NPS_ENET_DISABLE;
+ buf_int_enable.tx_done = NPS_ENET_ENABLE;
+ nps_enet_reg_set(priv, NPS_ENET_REG_BUF_INT_ENABLE,
+buf_int_enable.value);
__napi_schedule(>napi);
}
--
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/
[v1 0/6] *** nps_enet fixups ***
From: Noam Camus This patch set is a bunch of fixes to make nps_enet work correctly with all platforms, i.e. real device, emulation system, and simulation system. The main trigger for this patch set was that in our emulation system the TX end interrupt is "edge-sensitive" and therefore we cannot use the cause register since it is not sticky. Also: TX is handled during HW interrupt context and not NAPI job. race with TX done was fixed. added acknowledge for TX when device is "level sensitive". enable drop of control frames which is not needed for regular usage. So most of this patch set is about TX handling, which is now more complete. Noam Camus (6): NET: nps_enet: replace use of cause register NET: nps_enet: reduce processing latency. NET: nps_enet: TX done race condition NET: nps_enet: drop control frames NET: nps_enet: TX done acknowledge. NET: nps_enet: minor namespace cleanup drivers/net/ethernet/ezchip/nps_enet.c | 44 +-- drivers/net/ethernet/ezchip/nps_enet.h | 20 -- 2 files changed, 24 insertions(+), 40 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] selftests/zram: Adding zram tests
On 08/17/2015 02:39 PM, naresh.kamb...@linaro.org wrote:
From: Naresh Kamboju naresh.kamb...@linaro.org
Are you using git send-email to send this patch? Not sure why
I see this From and the one below.
zram.sh: sanity check of CONFIG_ZRAM and run zram01.sh and zram02.sh
zram01.sh: creates general purpose ram disks with different filesystems
zram02.sh: creates block device for swap
zram_lib.sh: create library with initialization/cleanup functions
README: ZRAM introduction and Kconfig required.
Makefile: To run zram tests
Could please write a proper commit message instead of list of files
and description.
From: Alexey Kodanev alexey.koda...@oracle.com
Same comment here.
CC: Shuah Khan shua...@osg.samsung.com
CC: Tyler Baker tyler.ba...@linaro.org
CC: Milosz Wasilewski milosz.wasilew...@linaro.org
Signed-off-by: Naresh Kamboju naresh.kamb...@linaro.org
Signed-off-by: Alexey Kodanev alexey.koda...@oracle.com
---
tools/testing/selftests/Makefile | 1 +
tools/testing/selftests/zram/Makefile| 12 ++
tools/testing/selftests/zram/README | 40 ++
tools/testing/selftests/zram/zram.sh | 22 +++
tools/testing/selftests/zram/zram01.sh | 98 ++
tools/testing/selftests/zram/zram02.sh | 53
tools/testing/selftests/zram/zram_lib.sh | 222
+++
7 files changed, 448 insertions(+)
create mode 100644 tools/testing/selftests/zram/Makefile
create mode 100644 tools/testing/selftests/zram/README
create mode 100755 tools/testing/selftests/zram/zram.sh
create mode 100755 tools/testing/selftests/zram/zram01.sh
create mode 100755 tools/testing/selftests/zram/zram02.sh
create mode 100755 tools/testing/selftests/zram/zram_lib.sh
diff --git a/tools/testing/selftests/Makefile
b/tools/testing/selftests/Makefile
index 24ae9e8..9763dd9 100644
--- a/tools/testing/selftests/Makefile
+++ b/tools/testing/selftests/Makefile
@@ -22,6 +22,7 @@ endif
TARGETS += user
TARGETS += vm
TARGETS += x86
+TARGETS += zram
#Please keep the TARGETS list alphabetically sorted
# Run make quicktest=1 run_tests or
# make quicktest=1 kselftest from top level Makefile
diff --git a/tools/testing/selftests/zram/Makefile
b/tools/testing/selftests/zram/Makefile
new file mode 100644
index 000..ec45513
--- /dev/null
+++ b/tools/testing/selftests/zram/Makefile
@@ -0,0 +1,12 @@
+all:
+
+TEST_PROGS := zram.sh
+TEST_FILES := zram01.sh zram02.sh zram_lib.sh
+
+include ../lib.mk
+
+run_tests:
+ @/bin/bash ./zram.sh
+
+clean:
+ $(RM) err.log
diff --git a/tools/testing/selftests/zram/README
b/tools/testing/selftests/zram/README
new file mode 100644
index 000..eb17917
--- /dev/null
+++ b/tools/testing/selftests/zram/README
@@ -0,0 +1,40 @@
+zram: Compressed RAM based block devices
+
+* Introduction
+
+The zram module creates RAM based block devices named /dev/zramid
+(id = 0, 1, ...). Pages written to these disks are compressed and stored
+in memory itself. These disks allow very fast I/O and compression provides
+good amounts of memory savings. Some of the usecases include /tmp storage,
+use as swap disks, various caches under /var and maybe many more :)
+
+Statistics for individual zram devices are exported through sysfs nodes at
+/sys/block/zramid/
+
+Kconfig required:
+CONFIG_ZRAM=y
+CONFIG_ZRAM_LZ4_COMPRESS=y
+CONFIG_ZPOOL=y
+CONFIG_ZSMALLOC=y
+
+ZRAM Testcases
+--
+zram_lib.sh: create library with initialization/cleanup functions
+zram.sh: For sanity check of CONFIG_ZRAM and to run zram01 and zram02
+
+Two functional tests: zram01 and zram02:
+zram01.sh: creates general purpose ram disks with ext4 filesystems
+zram02.sh: creates block device for swap
+
+Commands required for testing:
+ - bc
+ - dd
+ - free
+ - awk
+ - mkswap
+ - swapon
+ - swapoff
+ - mkfs/ mkfs.ext4
+
+For more information please refer:
+kernel-source-tree/Documentation/blockdev/zram.txt
diff --git a/tools/testing/selftests/zram/zram.sh
b/tools/testing/selftests/zram/zram.sh
new file mode 100755
index 000..be219fd
--- /dev/null
+++ b/tools/testing/selftests/zram/zram.sh
@@ -0,0 +1,22 @@
+#!/bin/bash
+TCID=zram.sh
+
+run_zram () {
+echo
+echo running zram tests
+echo
+./zram01.sh
+./zram02.sh
+}
+
+# check zram module exists
+MODULE_PATH=/lib/modules/`uname -r`/kernel/drivers/block/zram/zram.ko
+if [ -f $MODULE_PATH ]; then
+ run_zram
+elif [ -b /dev/zram0 ]; then
+ run_zram
+else
+ echo $TCID : No zram.ko module or /dev/zram0 device file not found
+ echo $TCID : CONFIG_ZRAM is not set
+ exit 1
+fi
diff --git a/tools/testing/selftests/zram/zram01.sh
b/tools/testing/selftests/zram/zram01.sh
new file mode 100755
index 000..2a2475d
--- /dev/null
+++ b/tools/testing/selftests/zram/zram01.sh
@@ -0,0 +1,98 @@
+#!/bin/bash
+#
Re: [RFC PATCH 1/7] x86, mm: ZONE_DEVICE for device memory
On Fri, Aug 14, 2015 at 07:11:27PM -0700, Dan Williams wrote:
On Fri, Aug 14, 2015 at 3:33 PM, Dan Williams dan.j.willi...@intel.com
wrote:
On Fri, Aug 14, 2015 at 3:06 PM, Jerome Glisse j.gli...@gmail.com wrote:
On Fri, Aug 14, 2015 at 02:52:15PM -0700, Dan Williams wrote:
On Fri, Aug 14, 2015 at 2:37 PM, Jerome Glisse j.gli...@gmail.com wrote:
On Wed, Aug 12, 2015 at 11:50:05PM -0400, Dan Williams wrote:
[..]
What is the rational for not updating max_pfn, max_low_pfn, ... ?
The idea is that this memory is not meant to be available to the page
allocator and should not count as new memory capacity. We're only
hotplugging it to get struct page coverage.
But this sounds bogus to me to rely on max_pfn to stay smaller than
first_dev_pfn. For instance you might plug a device that register
dev memory and then some regular memory might be hotplug, effectively
updating max_pfn to a value bigger than first_dev_pfn.
True.
Also i do not think that the buddy allocator use max_pfn or max_low_pfn
to consider page/zone for allocation or not.
Yes, I took it out with no effects. I'll investigate further whether
we should be touching those variables or not for this new usage.
Although it does not offer perfect protection if device memory is at a
physically lower address than RAM, skipping the update of these
variables does seem to be what we want. For example /dev/mem would
fail to allow write access to persistent memory if it fails a
valid_phys_addr_range() check. Since /dev/mem does not know how to
write to PMEM in a reliably persistent way, it should not treat a
PMEM-pfn like RAM.
So i attach is a patch that should keep ZONE_DEVICE out of consideration
for the buddy allocator. You might also want to keep page reserved and not
free inside the zone, you could replace the generic_online_page() using
set_online_page_callback() while hotpluging device memory.
Regarding /dev/mem i would not worry about highmem, as /dev/mem is already
broken in respect to memory hole that might exist (at least that is my
understanding). Alternatively if you really care about /dev/mem you could
add an arch valid_phys_addr_range() that could check valid zone.
Cheers,
Jérôme
From 45976e1186eee45ecb277fe5293a7cfa7466d740 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Glisse?= jgli...@redhat.com
Date: Mon, 17 Aug 2015 17:31:27 -0400
Subject: [PATCH] mm/ZONE_DEVICE: Keep ZONE_DEVICE out of allocation zonelist.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Memory inside a ZONE_DEVICE should never be consider by the buddy
allocator and thus any such zone should never be added to any of
the zonelist. This patch just do that.
Signed-off-by: Jérôme Glisse jgli...@redhat.com
---
mm/page_alloc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index ef19f22..f3e26de 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3834,6 +3834,13 @@ static int build_zonelists_node(pg_data_t *pgdat, struct
zonelist *zonelist,
do {
zone_type--;
zone = pgdat-node_zones + zone_type;
+ /*
+* Device zone is special memory and should never be consider
+* for regular allocation. It is expected that page in device
+* zone will be allocated by other means.
+*/
+ if (is_dev_zone(zone))
+ continue;
if (populated_zone(zone)) {
zoneref_set_zone(zone,
zonelist-_zonerefs[nr_zones++]);
--
1.8.3.1
Re: [PATCH v4] pinctrl: mediatek: Implement wake handler and suspend resume
On Mon, 2015-08-17 at 21:25 +0800, Yingjoe Chen wrote:
On Mon, 2015-08-17 at 17:09 +0800, Daniel Kurtz wrote:
On Mon, Aug 17, 2015 at 3:52 PM, Yingjoe Chen yingjoe.c...@mediatek.com
wrote:
On Fri, 2015-08-14 at 16:38 +0800, maoguang.m...@mediatek.com wrote:
From: Maoguang Meng maoguang.m...@mediatek.com
This patch implement irq_set_wake to get who is wakeup source and
setup on suspend resume.
Signed-off-by: Maoguang Meng maoguang.m...@mediatek.com
---
changes since v3:
-add a comment in mtk_eint_chip_read_mask.
-delete ALIGN when allocate eint_offsets.ports.
-fix unrelated change.
changes since v2:
-modify irq_wake to handle irq wakeup source.
-allocate two buffers separately.
-fix some codestyle.
Changes since v1:
-implement irq_wake handler.
---
drivers/pinctrl/mediatek/pinctrl-mt8173.c | 1 +
drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 91
++-
drivers/pinctrl/mediatek/pinctrl-mtk-common.h | 4 ++
3 files changed, 95 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8173.c
b/drivers/pinctrl/mediatek/pinctrl-mt8173.c
index d0c811d..ad27184 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt8173.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt8173.c
@@ -385,6 +385,7 @@ static struct platform_driver mtk_pinctrl_driver = {
.driver = {
.name = mediatek-mt8173-pinctrl,
.of_match_table = mt8173_pctrl_match,
+ .pm = mtk_eint_pm_ops,
},
};
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
index ad1ea16..fe34ce9 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
@@ -33,6 +33,7 @@
#include linux/mfd/syscon.h
#include linux/delay.h
#include linux/interrupt.h
+#include linux/pm.h
#include dt-bindings/pinctrl/mt65xx.h
#include ../core.h
@@ -1062,6 +1063,77 @@ static int mtk_eint_set_type(struct irq_data *d,
return 0;
}
+static int mtk_eint_irq_set_wake(struct irq_data *d, unsigned int on)
+{
+ struct mtk_pinctrl *pctl = irq_data_get_irq_chip_data(d);
+ int shift = d-hwirq 0x1f;
+ int reg = d-hwirq 5;
+
+ if (on)
+ pctl-wake_mask[reg] |= BIT(shift);
+ else
+ pctl-wake_mask[reg] = ~BIT(shift);
+
+ return 0;
+}
Hi Maoguang,
You changed from set_bit/clear_bit to this, but didn't add any locking.
Since this is basic read/modify/write, is it OK to do it without
locking?
I believe calling .irq_set_wake() concurrently with itself is
protected by irq_get_desc_buslock():
int irq_set_irq_wake(unsigned int irq, unsigned int on)
{
unsigned long flags;
struct irq_desc *desc = irq_get_desc_buslock(irq, flags,
IRQ_GET_DESC_CHECK_GLOBAL);
int ret = 0;
...
ret = set_irq_wake_real(irq, on);
...
irq_put_desc_busunlock(desc, flags);
return ret;
}
Hi Dan,
You are right, irq_get_desc_buslock will acquire desc lock even when
irq_chip didn't provide irq_bus_lock callback. So this should be OK.
Sorry for the noise.
For this patch:
Acked-by: Yingjoe Chen yingjoe.c...@mediatek.com
Joe.C
Acked-by: Hongzhou Yang hongzhou.y...@mediatek.com
Thanks.
Hongzhou
--
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/
[tip:timers/core] hrtimer: Drop return code of hrtimer_switch_to_hres()
Commit-ID: 75e3b37d059856a972a5bf2bdfeac0f0f2db9ea3
Gitweb: http://git.kernel.org/tip/75e3b37d059856a972a5bf2bdfeac0f0f2db9ea3
Author: Luiz Capitulino lcapitul...@redhat.com
AuthorDate: Tue, 11 Aug 2015 16:40:43 -0400
Committer: Thomas Gleixner t...@linutronix.de
CommitDate: Mon, 17 Aug 2015 23:19:03 +0200
hrtimer: Drop return code of hrtimer_switch_to_hres()
It's not checked by the caller.
Signed-off-by: Luiz Capitulino lcapitul...@redhat.com
Link: http://lkml.kernel.org/r/20150811164043.53824...@redhat.com
Signed-off-by: Thomas Gleixner t...@linutronix.de
---
kernel/time/hrtimer.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/kernel/time/hrtimer.c b/kernel/time/hrtimer.c
index 5c7ae4b..55575d4 100644
--- a/kernel/time/hrtimer.c
+++ b/kernel/time/hrtimer.c
@@ -679,14 +679,13 @@ static void retrigger_next_event(void *arg)
/*
* Switch to high resolution mode
*/
-static int hrtimer_switch_to_hres(void)
+static void hrtimer_switch_to_hres(void)
{
struct hrtimer_cpu_base *base = this_cpu_ptr(hrtimer_bases);
if (tick_init_highres()) {
printk(KERN_WARNING Could not switch to high resolution
mode on CPU %d\n, base-cpu);
- return 0;
}
base-hres_active = 1;
hrtimer_resolution = HIGH_RES_NSEC;
@@ -694,7 +693,6 @@ static int hrtimer_switch_to_hres(void)
tick_setup_sched_timer();
/* Retrigger the interrupt to get things going */
retrigger_next_event(NULL);
- return 1;
}
static void clock_was_set_work(struct work_struct *work)
@@ -718,7 +716,7 @@ void clock_was_set_delayed(void)
static inline int __hrtimer_hres_active(struct hrtimer_cpu_base *b) { return
0; }
static inline int hrtimer_hres_active(void) { return 0; }
static inline int hrtimer_is_hres_enabled(void) { return 0; }
-static inline int hrtimer_switch_to_hres(void) { return 0; }
+static inline void hrtimer_switch_to_hres(void) { }
static inline void
hrtimer_force_reprogram(struct hrtimer_cpu_base *base, int skip_equal) { }
static inline int hrtimer_reprogram(struct hrtimer *timer,
--
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] mm/memblock: check memblock_reserve on fail in memblock_virt_alloc_internal
On Sun, 16 Aug 2015 00:26:46 +0600 Alexander Kuleshov kuleshovm...@gmail.com wrote: This patch adds a check for memblock_reserve() call in the memblock_virt_alloc_internal() function, because memblock_reserve() can return -errno on fail. ... --- a/mm/memblock.c +++ b/mm/memblock.c @@ -1298,7 +1298,9 @@ again: return NULL; done: - memblock_reserve(alloc, size); + if (memblock_reserve(alloc, size)) + return NULL; + ptr = phys_to_virt(alloc); memset(ptr, 0, size); This shouldn't ever happen. If it *does* happen, something is messed up and we should warn. -- 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 8/9] clocksource: Improve unstable clocksource detection
On Mon, 17 Aug 2015, John Stultz wrote:
From: Shaohua Li s...@fb.com
From time to time we saw TSC is marked as unstable in our systems, while
Stray ''
the CPUs declare to have stable TSC. Looking at the clocksource unstable
detection, there are two problems:
- watchdog clock source wrap. HPET is the most common watchdog clock
source. It's 32-bit and runs in 14.3Mhz. That means the hpet counter
can wrap in about 5 minutes.
- threshold isn't scaled against interval. The threshold is 0.0625s in
0.5s interval. What if the actual interval is bigger than 0.5s?
The watchdog runs in a timer bh, so hard/soft irq can defer its running.
Heavy network stack softirq can hog a cpu. IPMI driver can disable
interrupt for a very long time.
And they hold off the timer softirq for more than a second? Don't you
think that's the problem which needs to be fixed?
The first problem is mostly we are suffering I think.
So you think that's the root cause and because your patch makes it go
away it's not necessary to know for sure, right?
Here is a simple patch to fix the issues. If the waterdog doesn't run
waterdog?
for a long time, we ignore the detection.
What's 'long time'? Please explain the numbers chosen.
This should work for the two
Emphasis on 'should'?
problems. For the second one, we probably doen't need to scale if the
interval isn't very long.
-ENOPARSE
@@ -122,9 +122,10 @@ static int clocksource_watchdog_kthread(void *data);
static void __clocksource_change_rating(struct clocksource *cs, int rating);
/*
- * Interval: 0.5sec Threshold: 0.0625s
+ * Interval: 0.5sec MaxInterval: 1s Threshold: 0.0625s
*/
#define WATCHDOG_INTERVAL (HZ 1)
+#define WATCHDOG_MAX_INTERVAL_NS (NSEC_PER_SEC)
#define WATCHDOG_THRESHOLD (NSEC_PER_SEC 4)
static void clocksource_watchdog_work(struct work_struct *work)
@@ -217,7 +218,9 @@ static void clocksource_watchdog(unsigned long data)
continue;
/* Check the deviation from the watchdog clocksource. */
- if ((abs(cs_nsec - wd_nsec) WATCHDOG_THRESHOLD)) {
+ if ((abs(cs_nsec - wd_nsec) WATCHDOG_THRESHOLD)
+ cs_nsec WATCHDOG_MAX_INTERVAL_NS
+ wd_nsec WATCHDOG_MAX_INTERVAL_NS) {
So that adds a new opportunity for undiscovered wreckage:
clocksource_watchdog();
--- SMI skews TSC
looong_irq_disabled_region();
clocksource_watchdog(); --- Does not detect skew
and it will not detect it later on if that SMI was a one time event.
So 'fixing' the watchdog is the wrong approach. Fixing the stuff which
prevents the watchdog to run is the proper thing to do.
Thanks,
tglx
--
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 9/9] clocksource: Sanity check watchdog clocksource
On Mon, Aug 17, 2015 at 2:24 PM, Thomas Gleixner t...@linutronix.de wrote: On Mon, 17 Aug 2015, John Stultz wrote: From: Shaohua Li s...@fb.com Add a sanity check to make sure watchdog clocksource doesn't wrap too quickly. Too quickly for what? The maximum interval delay limit (which would prevent the logic from avoiding false positives) . I can try to expand this text and resend if you want. Aren't you on vacation? :) -john -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2] memory-barriers: remove smp_mb__after_unlock_lock()
On Mon, Aug 17, 2015 at 07:15:01AM +0100, Paul E. McKenney wrote: On Mon, Aug 17, 2015 at 02:06:07PM +1000, Michael Ellerman wrote: On Wed, 2015-08-12 at 08:43 -0700, Paul E. McKenney wrote: On Wed, Aug 12, 2015 at 02:44:15PM +0100, Will Deacon wrote: On Fri, Jul 24, 2015 at 04:30:46PM +0100, Paul E. McKenney wrote: On Fri, Jul 24, 2015 at 12:31:01PM +0100, Will Deacon wrote: On Wed, Jul 15, 2015 at 02:12:21PM +0100, Paul E. McKenney wrote: commit 695c05d4b9666c50b40a1c022678b5f6e2e3e771 Author: Paul E. McKenney paul...@linux.vnet.ibm.com Date: Tue Jul 14 18:35:23 2015 -0700 rcu,locking: Privatize smp_mb__after_unlock_lock() RCU is the only thing that uses smp_mb__after_unlock_lock(), and is likely the only thing that ever will use it, so this commit makes this macro private to RCU. Signed-off-by: Paul E. McKenney paul...@linux.vnet.ibm.com Cc: Will Deacon will.dea...@arm.com Cc: Peter Zijlstra pet...@infradead.org Cc: Benjamin Herrenschmidt b...@kernel.crashing.org Cc: linux-a...@vger.kernel.org linux-a...@vger.kernel.org Are you planning to queue this somewhere? I think it makes sense regardless of whether we change PowerPc or not and ideally it would be merged around the same time as my relaxed atomics series. I have is in -rcu. By default, I will push it to the 4.4 merge window. Please let me know if you need it sooner. The generic relaxed atomics are now queued in -tip, so it would be really good to see this Documentation update land in 4.3 if at all possible. I appreciate it's late in the cycle, but it's always worth asking. Can't hurt to give it a try. I have set -rcu's rcu/next branch to this commit, and if it passes a few day's worth of testing, I will see what Ingo has to say about a pull request. This commit also privatizes smp_mb__after_unlock_lock() as well as updating documentation. Looks like we need to strengthen powerpc's locking primitives, then get rid of smp_mb__after_unlock_lock() entirely. Or did that already happen and I just missed it? No it didn't. I thought the end result of this thread was that we didn't *need* to change the powerpc lock semantics? Or did I read it wrong? ie. the docs now say that RELEASE+ACQUIRE is not a full barrier, which is consistent with our current implementation. That change happened about 1.5 years ago, and I thought that the current discussion was about reversing it, based in part on the recent powerpc benchmarks of locking primitives with and without the sync instruction. But regardless, I clearly cannot remove either the smp_mb__after_unlock_lock() or the powerpc definition of it to be smp_mb() if powerpc unlock/lock is not strengthened. Yup. Peter and I would really like to get rid of smp_mb__after_unlock_lock entirely, which would mean strengthening the ppc spinlocks. Moving the barrier primitive into RCU is a good step to prevent more widespread usage of the barrier, but we'd really like to go further if the performance impact is deemed acceptable (which is what this thread is about). Will -- 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/4] PCI: pci-host-generic: Fix lookup of linux,pci-probe-only property
On Fri, Aug 14, 2015 at 09:26:21PM +0100, Bjorn Helgaas wrote: On Fri, Aug 14, 2015 at 11:43 AM, Will Deacon will.dea...@arm.com wrote: On Fri, Aug 14, 2015 at 05:40:51PM +0100, Bjorn Helgaas wrote: Do we need support for pci-probe-only in pci-host-generic at all? You're removing the use in amd-overdrive.dts, and there are no other DTs in the kernel tree that mention it. If we can live without it, that would be nice. It seems like a relic from days when we couldn't reliably assign resources. (I'm not saying we can do that reliably even today, but I'd rather make it reliable than turn it off.) Kvmtool certainly uses it (and generates its own DT, hence why you don't see it in mainline). Not sure about qemu, though. Do you know why kvmtool wants probe-only? Would something break if we didn't support probe-only? I guess we'd be looking for a case where Linux assigns resources and that assignment doesn't work with kvmtool? It's basically because the BARs aren't writable other than to find the region size. It could fixed with a bit of pain, but it doesn't help older kvmtools that do work with mainline today. Will -- 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/5] net: add Hisilicon Network Subsystem MDIO support
Thanks, Arnd,
You are right. This is the same IP as hip04_mdio.c. We just mis-understand the
hardware design. We will merge them and re-submit the patches.
On Fri, Aug 14, 2015 at 10:57:28PM +0200, Arnd Bergmann wrote:
On Friday 14 August 2015 18:30:20 Kenneth Lee wrote:
+#define MDIO_BASE_ADDR 0x403C
Does not belong in here (and is not used)
+#define MDIO_COMMAND_REG 0x0
+#define MDIO_ADDR_REG 0x4
+#define MDIO_WDATA_REG 0x8
+#define MDIO_RDATA_REG 0xc
+#define MDIO_STA_REG 0x10
These look suspiciously similar to definitions from
drivers/net/ethernet/hisilicon/hip04_mdio.c.
Could the hardware be related? If so, please try to share
the common parts.
+static inline void mdio_write_reg(void *base, u32 reg, u32 value)
+{
+ u8 __iomem *reg_addr = ACCESS_ONCE(base);
+
+ writel(value, reg_addr + reg);
+}
+
+#define MDIO_WRITE_REG(a, reg, value) \
+ mdio_write_reg((a)-vbase, (reg), (value))
Something seems wrong here: why do you have an ACCESS_ONCE() on a
local variable? Doesn't this just make the code less efficient
without providing lockless access to shared variables?
The types are inconsistent here, you should get a warning from
running this through 'make C=1' because of the missing __iomem
annotation of the pointer.
Also, why both a macro and an inline function? Just use an inline
function.
Arnd
--
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: 4.2.0-rc6+: Boot crash on IBM X346
IBM Xseries 346, 2x Xeon 3.2 HT 64-bit (4 threads total, P4 era Xeon), 5G RAM. All kernels so far worked fine, last working one was 4.2.0-rc2-00077-gf760b87. First kernel tested after that was v4.2-rc6-20-g7a834ba and that one crashes on boot. Same crash happens in 4.2.0-rc7. Screenshot at http://kodu.ut.ee/~mroos/x346-crash.jpg Config and dmesg from working 4.2.0-rc2-00077-gf760b87 are below. I can not bisect until next week. Will try to bisect, slowly as I have no remote management on that server. -- Meelis Roos (mr...@linux.ee) http://www.cs.ut.ee/~mroos/ -- 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] mmc: dw_mmc: fix pio mode when internal dmac is enabled
Hi, Ulf.
On 08/17/2015 07:16 PM, Ulf Hansson wrote:
On 3 August 2015 at 17:04, Heiko Stübner he...@sntech.de wrote:
The dw_mci_init_dma() may decide to not use dma, but pio instead, caused
by things like wrong dma settings in the system.
Till now the code dw_mci_init_slot() always assumed that dma is available
when CONFIG_MMC_DW_IDMAC was defined, ignoring the host-use_dma var
set during dma init.
So when now the dma init failed for whatever reason, the transfer sizes
would still be set for dma transfers, especially including the maximum
block-count calculated from host-ring_size and resulting in a
[4.991109] [ cut here ]
[4.99] kernel BUG at drivers/mmc/core/core.c:256!
[4.991113] Internal error: Oops - BUG: 0 [#1] SMP ARM
because host-ring_size is 0 in this case and the slot init code uses
the wrong code to calculate the values.
Fix this by selecting the correct calculations using the host-use_dma
variable instead of the CONFIG_MMC_DW_IDMAC config option.
Signed-off-by: Heiko Stuebner he...@sntech.de
---
drivers/mmc/host/dw_mmc.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 40e9d8e..9ec3521 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -2391,19 +2391,20 @@ static int dw_mci_init_slot(struct dw_mci *host,
unsigned int id)
mmc-max_seg_size = host-pdata-blk_settings-max_seg_size;
} else {
/* Useful defaults if platform data is unset. */
-#ifdef CONFIG_MMC_DW_IDMAC
- mmc-max_segs = host-ring_size;
- mmc-max_blk_size = 65536;
- mmc-max_seg_size = 0x1000;
- mmc-max_req_size = mmc-max_seg_size * host-ring_size;
- mmc-max_blk_count = mmc-max_req_size / 512;
-#else
- mmc-max_segs = 64;
- mmc-max_blk_size = 65536; /* BLKSIZ is 16 bits */
- mmc-max_blk_count = 512;
- mmc-max_req_size = mmc-max_blk_size * mmc-max_blk_count;
- mmc-max_seg_size = mmc-max_req_size;
-#endif /* CONFIG_MMC_DW_IDMAC */
+ if (host-use_dma) {
+ mmc-max_segs = host-ring_size;
I expect this may cause a compiler error since host-ring_size is only
available in the struct dw_mci *host when CONFIG_MMC_DW_IDMAC is set.
I have already pulled in this patch from Jaehoon's pull request.
Perhaps I should only amend the patch and change the host-ring_size
to be always available no matter if CONFIG_MMC_DW_IDMAC is set or not?
Sorry for this. if you can, i think good that CONFIG_MMC_DW_IDMAC is removed at
struct dw_mci.
Could you amend it?
If you want to get patch, i will send patch at now.
Best Regards,
Jaehoon Chung
+ mmc-max_blk_size = 65536;
+ mmc-max_seg_size = 0x1000;
+ mmc-max_req_size = mmc-max_seg_size *
host-ring_size;
+ mmc-max_blk_count = mmc-max_req_size / 512;
+ } else {
+ mmc-max_segs = 64;
+ mmc-max_blk_size = 65536; /* BLKSIZ is 16 bits */
+ mmc-max_blk_count = 512;
+ mmc-max_req_size = mmc-max_blk_size *
+ mmc-max_blk_count;
+ mmc-max_seg_size = mmc-max_req_size;
+ }
}
if (dw_mci_get_cd(mmc))
--
2.1.4
Kind regards
Uffe
--
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 kernel vfio] mm: vfio: Move pages out of CMA before pinning
On Mon, 2015-08-17 at 11:53 +0200, Vlastimil Babka wrote: I meant why the kernel used for QEMU has also CMA enabled and used (for something else)? CMA is mostly used on mobile devices and they don't run QEMU? I explained in a separeate reply but yes, we do use a CMA for KVM for our MMU hash tables. Cheers, Ben. -- 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] mmc: dw_mmc: fix pio mode when internal dmac is enabled
Am Montag, 17. August 2015, 12:34:09 schrieb Ulf Hansson:
[...]
- mmc-max_seg_size = mmc-max_req_size;
-#endif /* CONFIG_MMC_DW_IDMAC */
+ if (host-use_dma) {
+ mmc-max_segs = host-ring_size;
I expect this may cause a compiler error since host-ring_size is only
available in the struct dw_mci *host when CONFIG_MMC_DW_IDMAC is set.
I have already pulled in this patch from Jaehoon's pull request.
Perhaps I should only amend the patch and change the host-ring_size
to be always available no matter if CONFIG_MMC_DW_IDMAC is set or not?
Sorry for this. if you can, i think good that CONFIG_MMC_DW_IDMAC is
removed at struct dw_mci. Could you amend it?
If you want to get patch, i will send patch at now.
No worries, I amend the patch myself.
thanks and sorry for missing that bit.
Heiko
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 6/8] staging: add bindings document for simple fpga bus
On Thu 2015-08-13 12:37:30, at...@opensource.altera.com wrote:
From: Alan Tull at...@opensource.altera.com
New bindings document for simple fpga bus.
Signed-off-by: Alan Tull at...@opensource.altera.com
Acked-by: Pavel Machek pa...@ucw.cz
+ onchip_memory2_0: memory@0x0 {
+ device_type = memory;
+ compatible = ALTR,onchipmem-15.1;
I guess this should be altr, .
+ jtag_uart: serial@0x10002 {
+ compatible = altr,juart-15.1,
altr,juart-1.0;
+ reg = 0x0001 0x0002
0x0008;
+ interrupt-parent = intc;
Best regards,
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures)
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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] mmc: sdhci: also set driver type for MMC_DDR52
On Mon, 17 Aug 2015 19:47:21 +0800
Jisheng Zhang jszh...@marvell.com wrote:
commit bb8175a8aa42 (mmc: sdhci: clarify DDR timing mode between
SD-UHS and eMMC) added MMC_DDR52 as eMMC's DDR mode to be
distinguished from SD-UHS, but it missed setting driver type for
MMC_DDR52 timing mode. This patches adds the missing driver type
setting.
This patch fixes unstable emmc read/write on marvell BG2Q DMP board.
Fixes: bb8175a8aa42 (mmc: sdhci: clarify DDR timing mode ...)
Signed-off-by: Jisheng Zhang jszh...@marvell.com
---
drivers/mmc/host/sdhci.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 1dbe932..32f2a07 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1559,7 +1559,8 @@ static void sdhci_do_set_ios(struct sdhci_host *host,
struct mmc_ios *ios)
(ios-timing == MMC_TIMING_UHS_SDR25) ||
(ios-timing == MMC_TIMING_UHS_SDR50) ||
(ios-timing == MMC_TIMING_UHS_SDR104) ||
- (ios-timing == MMC_TIMING_UHS_DDR50))) {
+ (ios-timing == MMC_TIMING_UHS_DDR50) ||
+ (ios-timing == MMC_TIMING_MMC_DDR52))) {
I'm not sure whether MMC_HS400 need such fix or not.
u16 preset;
sdhci_enable_preset_value(host, true);
--
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] [SCSI] bfa: check if port is non NULL before dereferencing
In bfa_fcs_lport_get_rport_max_speed() check if port is non NULL before dereferencing it's child port-fcs-bfa to trl_enabled. NB: I'm not entirely sure if port can even be NULL, so the check for NULL might be useless as well. Signed-off-by: Johannes Thumshirn jthumsh...@suse.de --- drivers/scsi/bfa/bfa_fcs_lport.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/bfa/bfa_fcs_lport.c b/drivers/scsi/bfa/bfa_fcs_lport.c index ff75ef8..096c2a2 100644 --- a/drivers/scsi/bfa/bfa_fcs_lport.c +++ b/drivers/scsi/bfa/bfa_fcs_lport.c @@ -5826,12 +5826,14 @@ bfa_fcs_lport_get_rport_max_speed(bfa_fcs_lport_t *port) bfa_port_speed_t max_speed = 0; struct bfa_port_attr_s port_attr; bfa_port_speed_t port_speed, rport_speed; - bfa_boolean_t trl_enabled = bfa_fcport_is_ratelim(port-fcs-bfa); + bfa_boolean_t trl_enabled; if (port == NULL) return 0; + trl_enabled = bfa_fcport_is_ratelim(port-fcs-bfa); + fcs = port-fcs; /* Get Physical port's current speed */ -- 2.5.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 5/8] staging: usage documentation for simple fpga bus
On Thu 2015-08-13 12:37:29, at...@opensource.altera.com wrote: From: Alan Tull at...@opensource.altera.com Add a document spelling out usage of the simple fpga bus. Signed-off-by: Alan Tull at...@opensource.altera.com Acked-by: Pavel Machek pa...@denx.de Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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] RDMSR before test_cpu_capacity brings about KVM warning
Huaitong Han huaitong@intel.com writes: rdmsrl_safe does not lead to #GP in native kernel although CPU does not support INTEL_PT, but if KVM does not support INTEL_PT, the codes cannot understand MSR_IA32_RTIT_CTL, and the warning is produced. the codes? If KVM does not support INTEL_PT, its guest CPUID also does not. So test_cpu_cap is added before RDMSR, and it is more in line with the code style. It does make more sense like this, but please improve this commit message. And don't forget to include Peter in the loop. FWIW, Reviewed-by: Alexander Shishkin alexander.shish...@linux.intel.com Regards, -- Alex -- 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 0/6] iio: bmg160: Add SPI connection
-Original Message-
From: Lars-Peter Clausen [mailto:l...@metafoo.de]
Sent: 12 August, 2015 18:04
To: Markus Pargmann; Jonathan Cameron
Cc: Srinivas Pandruvada; Dogaru, Vlad; Paul Bolle; linux-...@vger.kernel.org;
linux-kernel@vger.kernel.org; ker...@pengutronix.de;
Tirdea, Irina
Subject: Re: [PATCH v3 0/6] iio: bmg160: Add SPI connection
Hi,
Markus and Irina can you try to synchronize your efforts. This series will
conflict with http://marc.info/?l=linux-iiom=143938994602171w=2
Hi Lars,
Good catch, especially since those patches might have been merged
through another tree. Completely missed this one.
I think it would be best if the multi-read emulation support is added to
regmap (which I think Markus' earlier series did).
I think my i2c controllers will work directly with regmap_bulk_read,
so I probably won't need additional changes for regmap. I will rebase
the bmg160 patches on top of the ones that add regmap support.
Thanks,
Irina
- Lars
On 08/12/2015 04:50 PM, Markus Pargmann wrote:
Hi,
bmg160 and bmi055 can be used via I2C and SPI. This series converts the
driver
to regmap and splits core driver and I2C/SPI.
Changes in v3:
- removed 'select REGMAP' as it is selected by REGMAP_I2C
- added EXPORT_SYMBOL_GPL for the core functions
- removed default values from regmap_config
- Added max_register and unset use_single_rw in regmap_config
- Changed Makefile to always compile bmg160-core with either spi or i2c.
It is
not possible now to compile the core alone.
Changes in v2:
- Added the id-name from the SPI driver to be used as iio device name
- Fixed Kconfig in patch 2 to add selects for REGMAP_I2C
- Fixed regmap configs to be static const
Best regards,
Markus
Markus Pargmann (6):
iio: bmg160: Use i2c regmap instead of direct i2c access
iio: bmg160: Remove i2c_client from data struct
iio: bmg160: Use generic dev_drvdata
iio: bmg160: Remove remaining uses of i2c_client
iio: bmg160: Separate i2c and core driver
iio: bmg160: Add SPI driver
drivers/iio/gyro/Kconfig | 28 ++-
drivers/iio/gyro/Makefile| 3 +-
drivers/iio/gyro/bmg160.h| 10 +
drivers/iio/gyro/{bmg160.c = bmg160_core.c} | 358
+++
drivers/iio/gyro/bmg160_i2c.c| 71 ++
drivers/iio/gyro/bmg160_spi.c| 57 +
6 files changed, 306 insertions(+), 221 deletions(-)
create mode 100644 drivers/iio/gyro/bmg160.h
rename drivers/iio/gyro/{bmg160.c = bmg160_core.c} (74%)
create mode 100644 drivers/iio/gyro/bmg160_i2c.c
create mode 100644 drivers/iio/gyro/bmg160_spi.c
--
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 net-next v5 00/11] ipv6: Only create RTF_CACHE route after encountering pmtu exception
Am 15.08.2015 um 09:48 schrieb Alexander Holler: Am 30.07.2015 um 13:57 schrieb Alexander Holler: Am 29.07.2015 um 11:25 schrieb Alexander Holler: Am 23.05.2015 um 05:55 schrieb Martin KaFai Lau: To complete the discussion, that annoying behaviour is also a big information leak. Because routes aren't considered confidential and aren't subject to privacy, that broken behaviour enabled *everyone* on the same system to see *all* the remote IPv6 systems to which there have been connection establishment tries. Just in case I haven't described the problem I see clearly enough: Everyone means everything (other SW) too, and if Happy_Eyeballs algorithms are used (see RFC 6555), this also affects systems which only have an IPv4 connection to the world, as long as IPv6 is enabled. That means it does not only affect multiuser systems and the current behaviour of kernels 4.2 renders e.g. the private mode of most browsers somewhat useless too (in regard to protection against other SW and/or users running on the same system). That's why I vote to check out if it's possible/reasonable to backport this series to the stable kernels. Regards, Alexander Holler -- 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: [RFCv5 PATCH 41/46] sched/fair: add triggers for OPP change requests
On 14 August 2015 at 13:39, Juri Lelli juri.le...@arm.com wrote:
Hi vincent,
On 13/08/15 13:08, Vincent Guittot wrote:
On 12 August 2015 at 17:15, Juri Lelli juri.le...@arm.com wrote:
On 11/08/15 17:37, Vincent Guittot wrote:
On 11 August 2015 at 17:07, Juri Lelli juri.le...@arm.com wrote:
Hi Vincent,
On 11/08/15 12:41, Vincent Guittot wrote:
On 11 August 2015 at 11:08, Juri Lelli juri.le...@arm.com wrote:
On 10/08/15 16:07, Vincent Guittot wrote:
On 10 August 2015 at 15:43, Juri Lelli juri.le...@arm.com wrote:
Hi Vincent,
On 04/08/15 14:41, Vincent Guittot wrote:
Hi Juri,
On 7 July 2015 at 20:24, Morten Rasmussen morten.rasmus...@arm.com
wrote:
From: Juri Lelli juri.le...@arm.com
[snip]
}
@@ -4393,6 +4416,23 @@ static void dequeue_task_fair(struct rq *rq,
struct task_struct *p, int flags)
if (!se) {
sub_nr_running(rq, 1);
update_rq_runnable_avg(rq, 1);
+ /*
+* We want to trigger a freq switch request only
for tasks that
+* are going to sleep; this is because we get here
also during
+* load balancing, but in these cases it seems wise
to trigger
+* as single request after load balancing is done.
+*
+* Also, we add a margin (same ~20% used for the
tipping point)
+* to our request to provide some head room if p's
utilization
+* further increases.
+*/
+ if (sched_energy_freq() task_sleep) {
+ unsigned long req_cap =
get_cpu_usage(cpu_of(rq));
+
+ req_cap = req_cap * capacity_margin
+SCHED_CAPACITY_SHIFT;
+ cpufreq_sched_set_cap(cpu_of(rq), req_cap);
Could you clarify why you want to trig a freq switch for tasks that
are going to sleep ?
The cpu_usage should not changed that much as the se_utilization of
the entity moves from utilization_load_avg to utilization_blocked_avg
of the rq and the usage and the freq are updated periodically.
I think we still need to cover multiple back-to-back dequeues. Suppose
that you have, let's say, 3 tasks that get enqueued at the same time.
After some time the first one goes to sleep and its utilization, as
you
say, gets moved to utilization_blocked_avg. So, nothing changes, and
the trigger is superfluous (even if no freq change I guess will be
issued as we are already servicing enough capacity). However, after a
while, the second task goes to sleep. Now we still use get_cpu_usage()
and the first task contribution in utilization_blocked_avg should have
been decayed by this time. Same thing may than happen for the third
task
as well. So, if we don't check if we need to scale down in
dequeue_task_fair, it seems to me that we might miss some
opportunities,
as blocked contribution of other tasks could have been successively
decayed.
What you think?
The tick is used to monitor such variation of the usage (in both way,
decay of the usage of sleeping tasks and increase of the usage of
running tasks). So in your example, if the duration between the sleep
of the 2 tasks is significant enough, the tick will handle this
variation
The tick is used to decide if we need to scale up (to max OPP for the
time being), but we don't scale down. It makes more logical sense to
why don't you want to check if you need to scale down ?
Well, because if I'm still executing something the cpu usage is only
subject to raise.
This is only true for system with NO HZ idle
Well, even with !NO_HZ_IDLE usage only decreases when cpu is idle. But,
Well, thanks for this obvious statement that usage only decreases when
cpu is idle but my question has never been about usage variation of
idle/running cpu but about the tick.
I'm sorry if I sounded haughty to you, of course I didn't want too and
I apologize for that. I just wanted to state the obvious to confirm
myself that I understood your point, as I say below. :)
I think I got your point; for !NO_HZ_IDLE configurations we might end
up not scaling down frequency even if we have the tick running and
the cpu is idle. I might need some more time to think this through, but
it seems to me that we are still fine without an explicit trigger in
task_tick_fair(); if we are running a !NO_HZ_IDLE system we are probably
not so much concerned about power savings and still we react
to tasks waking up, sleeping, leaving or moving around (which seems the
real important events to me); OTOH, we might add that trigger, but this
will generate unconditional checks at tick time for NO_HZ_IDLE
That will be far less critical than unconditionally check during all
task wake up or sleep. A task that wakes up every 200us will generate
much more check in the wake up hot path of the cpu that is already
busy with another task
We have a throttling
Re: [RFC PATCH kernel vfio] mm: vfio: Move pages out of CMA before pinning
On 08/17/2015 11:11 AM, Alexey Kardashevskiy wrote: On 08/17/2015 05:45 PM, Vlastimil Babka wrote: On 08/05/2015 10:08 AM, Alexey Kardashevskiy wrote: This is about VFIO aka PCI passthrough used from QEMU. KVM is irrelevant here. QEMU is a machine emulator. It allocates guest RAM from anonymous memory and these pages are movable which is ok. They may happen to be allocated from the contiguous memory allocation zone (CMA). Which is also ok as long they are movable. However if the guest starts using VFIO (which can be hotplugged into the guest), in most cases it involves DMA which requires guest RAM pages to be pinned and not move once their addresses are programmed to the hardware for DMA. So we end up in a situation when quite many pages in CMA are not movable anymore. And we get bunch of these: [77306.513966] alloc_contig_range: [1f3800, 1f78c4) PFNs busy [77306.514448] alloc_contig_range: [1f3800, 1f78c8) PFNs busy [77306.514927] alloc_contig_range: [1f3800, 1f78cc) PFNs busy IIRC CMA was for mobile devices and their camera/codec drivers and you don't use QEMU on those? What do you need CMA for in your case? I do not want QEMU to get memory from CMA, this is my point. It just happens sometime that the kernel allocates movable pages from there. I meant why the kernel used for QEMU has also CMA enabled and used (for something else)? CMA is mostly used on mobile devices and they don't run QEMU? This is a very rough patch to start the conversation about how to move pages properly. mm/page_alloc.c does this and arch/powerpc/mm/mmu_context_iommu.c exploits it. OK such conversation should probably start by mentioning the VM_PINNED effort by Peter Zijlstra: https://lkml.org/lkml/2014/5/26/345 It's more general approach to dealing with pinned pages, and moving them out of CMA area (and compacting them in general) prior pinning is one of the things that should be done within that framework. And I assume these patches did not go anywhere, right?... Not yet :) Then there's the effort to enable migrating pages other than LRU during compaction (and thus CMA allocation): https://lwn.net/Articles/650864/ I don't know if that would be applicable in your use case, i.e. are the pins for DMA short-lived and can the isolation/migration code wait a bit for the transfer to finish so it can grab them, or something? Pins for DMA are long-lived, pretty much as long as the guest is running. So this compaction is too late. Oh, OK. Please do not comment on the style and code placement, this is just to give some context :) Obviously, this does not work well - it manages to migrate only few pages and crashes as it is missing locks/disabling interrupts and I probably should not just remove pages from LRU list (normally, I guess, only these can migrate) and a million of other things. The questions are: - what is the correct way of telling if the page is in CMA? is (get_pageblock_migratetype(page) == MIGRATE_CMA) good enough? Should be. - how to tell MM to move page away? I am calling migrate_pages() with an get_new_page callback which allocates a page with GFP_USER but without GFP_MOVABLE which should allocate new page out of CMA which seems ok but there is a little convern that we might want to add MOVABLE back when VFIO device is unplugged from the guest. Hmm, once the page is allocated, then the migratetype is not tracked anywhere (except in page_owner debug data). But the unmovable allocations might exhaust available unmovable pageblocks and lead to fragmentation. So add MOVABLE back would be too late. Instead we would need to tell the allocator somehow to give us movable page but outside of CMA. It is it movable, why do we care if it is in CMA or not? I did assume your pages are mostly movable, but with some temporary pins they might not be movable reliably at arbitrary time. But if you say the pins are long lived then it's probably best allocated without MOVABLE. If the device is later unplugged, sync compaction will eventually move the pages out of unmovable pageblocks. CMA's own __alloc_contig_migrate_range() avoids this problem by allocating movable pages, but the range has been already page-isolated and thus the allocator won't see the pages there.You obviously can't take this approach and isolate all CMA pageblocks like that. That smells like a new __GFP_FLAG, meh. I understood (more or less) all of it except the __GFP_FLAG - when/what would use it? Nevermind, wrt above. - do I need to isolate pages by using isolate_migratepages_range, reclaim_clean_pages_from_list like __alloc_contig_migrate_range does? I dropped them for now and the patch uses only @migratepages from the compact_control struct. You don't have to do reclaim_clean_pages_from_list(), but the isolation has to be careful, yeah. The isolation here means the whole CMA zone isolation which I obviously can't take this approach? :) Ah no, that's isolation from lru lists in this context.
Re: [PATCH 0/6] sched/fair: Compute capacity invariant load/utilization tracking
On Mon, Aug 17, 2015 at 12:29:51PM +0100, Morten Rasmussen wrote: On Sun, Aug 16, 2015 at 10:46:05PM +0200, Peter Zijlstra wrote: On Fri, Aug 14, 2015 at 05:23:08PM +0100, Morten Rasmussen wrote: Target: ARM TC2 A7-only (x3) Test: hackbench -g 25 --threads -l 1 BeforeAfter 315.545 313.408 -0.68% Target: Intel(R) Core(TM) i5 CPU M 520 @ 2.40GHz Test: hackbench -g 25 --threads -l 1000 (avg of 10) BeforeAfter 6.46436.395 -1.07% Yeah, so that is a problem. Maybe I'm totally wrong, but doesn't hackbench report execution so less is better? In that case -1.07% means we are doing better with the patches applied (after time before time). In any case, I should have indicated whether the change is good or bad for performance. I'm taking it some of the new scaling stuff doesn't compile away, can we look at fixing that? I will double-check that the stuff goes away as expected. I'm pretty sure it does on ARM. Ah, uhm.. you have a point there ;-) I'll run the numbers when I'm back home again. -- 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] pwrseq: bind pinctrl pins before using the gpios
Some of the pin-controllers like the Qualcomms qcom,pm8921, which
require a pinconf to be setup to use pins as gpios. Using the pins
directly without pinconf setup would result in incorrect output voltage
or load settings. On the other hand pwrseq code does not configure the
pinctrl by default as it does not go thru the driver core.
This patch adds a call to pinctrl_bind_pins() to bind pins which
are going to be used as gpios.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---
drivers/mmc/core/pwrseq.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/mmc/core/pwrseq.c b/drivers/mmc/core/pwrseq.c
index 4c1d175..6e5d8b3 100644
--- a/drivers/mmc/core/pwrseq.c
+++ b/drivers/mmc/core/pwrseq.c
@@ -12,6 +12,7 @@
#include linux/err.h
#include linux/of.h
#include linux/of_platform.h
+#include linux/pinctrl/devinfo.h
#include linux/mmc/host.h
@@ -65,6 +66,10 @@ int mmc_pwrseq_alloc(struct mmc_host *host)
goto err;
}
+ ret = pinctrl_bind_pins(pdev-dev);
+ if (ret)
+ goto err;
+
match = mmc_pwrseq_find(np);
if (IS_ERR(match)) {
ret = PTR_ERR(match);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: lustre: simplify ptlrpc_deactivate_and_unlock_import
The locking scheme used in ptlrpc_deactivate_and_unlock_import and
ptlrpc_deactivate_import generates the followings sparse errors:
drivers/staging/lustre/lustre/ptlrpc/import.c:209:9: warning: context
imbalance in 'ptlrpc_deactivate_and_unlock_import' - unexpected unlock
drivers/staging/lustre/lustre/ptlrpc/import.c:221:6: warning: context
imbalance in 'ptlrpc_deactivate_import' - wrong count at exit
As ptlrpc_deactivate_and_unlock_import is only used by
ptlrpc_deactivate_import as a helper function, this patch moves its code
into ptlrpc_deactivatre_import to fix the sparse warnings.
Signed-off-by: Maxime Lorrillere maxime.lorrill...@gmail.com
---
drivers/staging/lustre/lustre/ptlrpc/import.c | 21 +++--
1 file changed, 7 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/lustre/lustre/ptlrpc/import.c
b/drivers/staging/lustre/lustre/ptlrpc/import.c
index 1eae389..1fd8510 100644
--- a/drivers/staging/lustre/lustre/ptlrpc/import.c
+++ b/drivers/staging/lustre/lustre/ptlrpc/import.c
@@ -200,12 +200,15 @@ int ptlrpc_set_import_discon(struct obd_import *imp,
__u32 conn_cnt)
return rc;
}
-/* Must be called with imp_lock held! */
-static void ptlrpc_deactivate_and_unlock_import(struct obd_import *imp)
+/*
+ * This acts as a barrier; all existing requests are rejected, and
+ * no new requests will be accepted until the import is valid again.
+ */
+void ptlrpc_deactivate_import(struct obd_import *imp)
{
- assert_spin_locked(imp-imp_lock);
-
CDEBUG(D_HA, setting import %s INVALID\n, obd2cli_tgt(imp-imp_obd));
+
+ spin_lock(imp-imp_lock);
imp-imp_invalid = 1;
imp-imp_generation++;
spin_unlock(imp-imp_lock);
@@ -213,16 +216,6 @@ static void ptlrpc_deactivate_and_unlock_import(struct
obd_import *imp)
ptlrpc_abort_inflight(imp);
obd_import_event(imp-imp_obd, imp, IMP_EVENT_INACTIVE);
}
-
-/*
- * This acts as a barrier; all existing requests are rejected, and
- * no new requests will be accepted until the import is valid again.
- */
-void ptlrpc_deactivate_import(struct obd_import *imp)
-{
- spin_lock(imp-imp_lock);
- ptlrpc_deactivate_and_unlock_import(imp);
-}
EXPORT_SYMBOL(ptlrpc_deactivate_import);
static unsigned int
--
2.5.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 4.2-rc6 regression: RIP: e030:[ffffffff8110fb18] [ffffffff8110fb18] detach_if_pending+0x18/0x80
Saturday, August 15, 2015, 12:39:25 AM, you wrote: On Sat, 2015-08-15 at 00:09 +0200, Sander Eikelenboom wrote: On 2015-08-13 00:41, Eric Dumazet wrote: On Wed, 2015-08-12 at 23:46 +0200, Sander Eikelenboom wrote: Thanks for the reminder, but luckily i was aware of that, seen enough of your replies asking for patches to be resubmitted against the other tree ;) Kernel with patch is currently running so fingers crossed. Thanks for testing. I am definitely interested knowing your results. Hmm it seems now commit 83fccfc3940c4a2db90fd7e7079f5b465cd8c6af is breaking things (have to test if a revert helps) i get this in some guests: Yes, this was fixed by : http://git.kernel.org/cgit/linux/kernel/git/davem/net.git/commit/?id=83fccfc3940c4a2db90fd7e7079f5b465cd8c6af Hi Eric, With that patch i had a crash again this night, see below. -- Sander [177459.188808] general protection fault: [#1] SMP [177459.199746] Modules linked in: [177459.210540] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.2.0-rc6-20150815-linus-doflr-net+ #1 [177459.221441] Hardware name: MSI MS-7640/890FXA-GD70 (MS-7640) , BIOS V1.8B1 09/13/2010 [177459.232247] task: 8221a580 ti: 8220 task.ti: 8220 [177459.242931] RIP: e030:[8110eb58] [8110eb58] detach_if_pending+0x18/0x80 [177459.253503] RSP: e02b:88005f6039d8 EFLAGS: 00010086 [177459.264051] RAX: 8800584d6580 RBX: 880004901420 RCX: dead00200200 [177459.274599] RDX: RSI: 88005f60e5c0 RDI: 880004901420 [177459.285122] RBP: 88005f6039d8 R08: 0001 R09: [177459.295286] R10: 0003 R11: 880004901394 R12: 0003 [177459.305388] R13: 00010ae47040 R14: 07b98a00 R15: 88005f60e5c0 [177459.315345] FS: 7f51317ec700() GS:88005f60() knlGS: [177459.325340] CS: e033 DS: ES: CR0: 8005003b [177459.335217] CR2: 010f8000 CR3: 2a154000 CR4: 0660 [177459.345129] Stack: [177459.354783] 88005f603a28 8110ee7f 810fb261 0200 [177459.364505] 0003 880004901380 0003 8800567d0d00 [177459.374064] 07b98a00 88005f603a58 819b3eb3 [177459.383532] Call Trace: [177459.392878] IRQ [177459.392935] [8110ee7f] mod_timer_pending+0x3f/0xe0 [177459.411058] [810fb261] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x20 [177459.419876] [819b3eb3] __nf_ct_refresh_acct+0xa3/0xb0 [177459.428642] [819baafb] tcp_packet+0xb3b/0x1290 [177459.437285] [81a2535e] ? ip_output+0x5e/0xc0 [177459.445845] [810ca8ca] ? __local_bh_enable_ip+0x2a/0x90 [177459.454331] [819b35a9] ? __nf_conntrack_find_get+0x129/0x2a0 [177459.462642] [819b549c] nf_conntrack_in+0x29c/0x7c0 [177459.470711] [81a65e9c] ipv4_conntrack_local+0x4c/0x50 [177459.478753] [819ad67c] nf_iterate+0x4c/0x80 [177459.486726] [81102437] ? generic_handle_irq+0x27/0x40 [177459.494634] [819ad714] nf_hook_slow+0x64/0xc0 [177459.502486] [81a22d40] __ip_local_out_sk+0x90/0xa0 [177459.510248] [81a22c40] ? ip_forward_options+0x1a0/0x1a0 [177459.517782] [81a22d66] ip_local_out_sk+0x16/0x40 [177459.525044] [81a2343d] ip_queue_xmit+0x14d/0x350 [177459.532247] [81a3ae7e] tcp_transmit_skb+0x48e/0x960 [177459.539413] [81a3cddb] tcp_xmit_probe_skb+0xdb/0xf0 [177459.546389] [81a3dffb] tcp_write_wakeup+0x5b/0x150 [177459.553061] [81a3e51b] tcp_keepalive_timer+0x1fb/0x230 [177459.559761] [81a3e320] ? tcp_init_xmit_timers+0x20/0x20 [177459.566447] [8110f3c7] call_timer_fn.isra.27+0x17/0x80 [177459.573121] [81a3e320] ? tcp_init_xmit_timers+0x20/0x20 [177459.579778] [8110f55d] run_timer_softirq+0x12d/0x200 [177459.586448] [810ca6c3] __do_softirq+0x103/0x210 [177459.593138] [810ca9cb] irq_exit+0x4b/0xa0 [177459.599783] [814f05d4] xen_evtchn_do_upcall+0x34/0x50 [177459.606300] [81af93ae] xen_do_hypervisor_callback+0x1e/0x40 [177459.612583] EOI [177459.612637] [810013aa] ? xen_hypercall_sched_op+0xa/0x20 [177459.625010] [810013aa] ? xen_hypercall_sched_op+0xa/0x20 [177459.631157] [81008d60] ? xen_safe_halt+0x10/0x20 [177459.637158] [810188d3] ? default_idle+0x13/0x20 [177459.643072] [81018e1a] ? arch_cpu_idle+0xa/0x10 [177459.648809] [810f8e7e] ? default_idle_call+0x2e/0x50 [177459.654650] [810f9112] ? cpu_startup_entry+0x272/0x2e0 [177459.660488] [81ae79f7] ? rest_init+0x77/0x80 [177459.666297] [82312f58] ? start_kernel+0x43b/0x448 [177459.672092] [823124ef] ? x86_64_start_reservations+0x2a/0x2c [177459.677800] [82316008] ? xen_start_kernel+0x550/0x55c
[PATCH v4 5/5] MAINTAINERS: Add Altera PCIe and MSI drivers maintainer
Signed-off-by: Ley Foon Tan lf...@altera.com --- MAINTAINERS | 16 1 file changed, 16 insertions(+) diff --git a/MAINTAINERS b/MAINTAINERS index fd60784..32f5287 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -7759,6 +7759,14 @@ F: include/linux/pci* F: arch/x86/pci/ F: arch/x86/kernel/quirks.c +PCI DRIVER FOR ALTERA PCIE IP +M: Ley Foon Tan lf...@altera.com +L: r...@lists.rocketboards.org (moderated for non-subscribers) +L: linux-...@vger.kernel.org +S: Supported +F: Documentation/devicetree/bindings/pci/altera-pcie.txt +F: drivers/pci/host/pcie-altera.c + PCI DRIVER FOR ARM VERSATILE PLATFORM M: Rob Herring r...@kernel.org L: linux-...@vger.kernel.org @@ -7860,6 +7868,14 @@ L: linux-...@vger.kernel.org S: Maintained F: drivers/pci/host/*spear* +PCI MSI DRIVER FOR ALTERA MSI IP +M: Ley Foon Tan lf...@altera.com +L: r...@lists.rocketboards.org (moderated for non-subscribers) +L: linux-...@vger.kernel.org +S: Supported +F: Documentation/devicetree/bindings/pci/altera-pcie-msi.txt +F: drivers/pci/host/pcie-altera-msi.c + PCI MSI DRIVER FOR APPLIEDMICRO XGENE M: Duc Dang dhd...@apm.com L: linux-...@vger.kernel.org -- 1.8.2.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 4/5] Documentation: dt-bindings: pci: altera pcie device tree binding
This patch adds the bindings for Altera PCIe host controller driver and
Altera PCIe MSI driver.
Signed-off-by: Ley Foon Tan lf...@altera.com
---
.../devicetree/bindings/pci/altera-pcie-msi.txt| 27
.../devicetree/bindings/pci/altera-pcie.txt| 49 ++
2 files changed, 76 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pci/altera-pcie-msi.txt
create mode 100644 Documentation/devicetree/bindings/pci/altera-pcie.txt
diff --git a/Documentation/devicetree/bindings/pci/altera-pcie-msi.txt
b/Documentation/devicetree/bindings/pci/altera-pcie-msi.txt
new file mode 100644
index 000..7f330c9
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/altera-pcie-msi.txt
@@ -0,0 +1,27 @@
+* Altera PCIe MSI controller
+
+Required properties:
+- compatible: should contain altr,msi-1.0
+- reg: specifies the physical base address of the controller and
+ the length of the memory mapped region.
+- reg-names: Must include the following entries:
+ csr: CSR registers
+ vector_slave: vectors region
+-interrupts: specifies the interrupt source of the parent interrupt
+ controller. The format of the interrupt specifier depends on the
+ parent interrupt controller.
+- num-vectors: Number of vectors, range 1 to 32.
+- msi-controller: indicates that this is MSI controller node
+
+
+Example
+msi0: msi@0xFF20 {
+ compatible = altr,msi-1.0;
+ reg = 0xFF20 0x0010
+ 0xFF200010 0x0080;
+ reg-names = csr, vector_slave;
+ interrupt-parent = hps_0_arm_gic_0;
+ interrupts = 0 42 4;
+ msi-controller = 1;
+ num-vectors = 32;
+};
diff --git a/Documentation/devicetree/bindings/pci/altera-pcie.txt
b/Documentation/devicetree/bindings/pci/altera-pcie.txt
new file mode 100644
index 000..73a8dc0
--- /dev/null
+++ b/Documentation/devicetree/bindings/pci/altera-pcie.txt
@@ -0,0 +1,49 @@
+* Altera PCIe controller
+
+Required properties:
+- compatible : should contain altr,pcie-root-port-1.0
+- reg: A list of physical base address and length for TXS and CRA.
+- reg-names: Must include the following entries:
+ Txs or txs: TXS region
+ Cra or cra: Control register access region
+-interrupts: specifies the interrupt source of the parent interrupt
controller.
+ The format of the interrupt specifier depends on the parent
interrupt
+ controller.
+- device_type: must be pci
+- #address-cells: set to 3
+- #size-cells: set to 2
+- #interrupt-cells:set to 1
+- ranges: Describes the translation of addresses for root ports
and standard
+ PCI regions.
+- interrupt-map-mask and interrupt-map: standard PCI properties
+ to define the mapping of the PCIe interface to interrupt
+ numbers.
+
+Optional properties:
+- msi-parent: Link to the hardware entity that serves as the MSI controller
for this PCIe
+ controller.
+- bus-range: PCI bus numbers covered
+
+Example
+ pcie_0: pcie@0xc {
+ compatible = altr,pcie-root-port-1.0;
+ reg = 0xc000 0x2000,
+ 0xff22 0x4000;
+ reg-names = Txs, Cra;
+ interrupt-parent = hps_0_arm_gic_0;
+ interrupts = 0 40 4;
+ interrupt-controller;
+ #interrupt-cells = 1;
+ bus-range = 0x0 0xFF;
+ device_type = pci;
+ msi-parent = msi_to_gic_gen_0;
+ #address-cells = 3;
+ #size-cells = 2;
+ interrupt-map-mask = 0 0 0 7;
+ interrupt-map = 0 0 0 1 pcie_0 1,
+ 0 0 0 2 pcie_0 2,
+ 0 0 0 3 pcie_0 3,
+ 0 0 0 4 pcie_0 4;
+ ranges = 0x8200 0x 0x 0xc000
0x 0x1000
+ 0x8200 0x 0x1000 0xd000
0x 0x1000;
+ };
--
1.8.2.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/
[RESEND PATCH 2/3 v6] cpufreq: mediatek: Add MT8173 cpufreq driver
Mediatek MT8173 is an ARMv8 based quad-core (2*Cortex-A53 and
2*Cortex-A72) SoC with duall clusters. For each cluster, two voltage
inputs, Vproc and Vsram are supplied by two regulators. For the big
cluster, two regulators come from different PMICs. In this case, when
scaling voltage inputs of the cluster, the voltages of two regulator
inputs need to be controlled by software explicitly under the SoC
specific limitation:
100mV Vsram - Vproc 200mV
which is called 'voltage tracking' mechanism. And when scaling the
frequency of cluster clock input, the input MUX need to be parented to
another intermediate stable PLL first and reparented to the original
PLL once the original PLL is stable at the target frequency. This patch
implements those mechanisms to enable CPU DVFS support for Mediatek
MT8173 SoC.
Signed-off-by: Pi-Cheng Chen pi-cheng.c...@linaro.org
Acked-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers/cpufreq/Kconfig.arm | 7 +
drivers/cpufreq/Makefile | 1 +
drivers/cpufreq/mt8173-cpufreq.c | 524 +++
3 files changed, 532 insertions(+)
create mode 100644 drivers/cpufreq/mt8173-cpufreq.c
diff --git a/drivers/cpufreq/Kconfig.arm b/drivers/cpufreq/Kconfig.arm
index cc8a71c..2bacf24 100644
--- a/drivers/cpufreq/Kconfig.arm
+++ b/drivers/cpufreq/Kconfig.arm
@@ -130,6 +130,13 @@ config ARM_KIRKWOOD_CPUFREQ
This adds the CPUFreq driver for Marvell Kirkwood
SoCs.
+config ARM_MT8173_CPUFREQ
+ bool Mediatek MT8173 CPUFreq support
+ depends on ARCH_MEDIATEK REGULATOR
+ select PM_OPP
+ help
+ This adds the CPUFreq driver support for Mediatek MT8173 SoC.
+
config ARM_OMAP2PLUS_CPUFREQ
bool TI OMAP2+
depends on ARCH_OMAP2PLUS
diff --git a/drivers/cpufreq/Makefile b/drivers/cpufreq/Makefile
index 2169bf7..9c75faf 100644
--- a/drivers/cpufreq/Makefile
+++ b/drivers/cpufreq/Makefile
@@ -62,6 +62,7 @@ obj-$(CONFIG_ARM_HISI_ACPU_CPUFREQ) += hisi-acpu-cpufreq.o
obj-$(CONFIG_ARM_IMX6Q_CPUFREQ)+= imx6q-cpufreq.o
obj-$(CONFIG_ARM_INTEGRATOR) += integrator-cpufreq.o
obj-$(CONFIG_ARM_KIRKWOOD_CPUFREQ) += kirkwood-cpufreq.o
+obj-$(CONFIG_ARM_MT8173_CPUFREQ) += mt8173-cpufreq.o
obj-$(CONFIG_ARM_OMAP2PLUS_CPUFREQ)+= omap-cpufreq.o
obj-$(CONFIG_ARM_PXA2xx_CPUFREQ) += pxa2xx-cpufreq.o
obj-$(CONFIG_PXA3xx) += pxa3xx-cpufreq.o
diff --git a/drivers/cpufreq/mt8173-cpufreq.c b/drivers/cpufreq/mt8173-cpufreq.c
new file mode 100644
index 000..763f1e3
--- /dev/null
+++ b/drivers/cpufreq/mt8173-cpufreq.c
@@ -0,0 +1,524 @@
+/*
+ * Copyright (c) 2015 Linaro Ltd.
+ * Author: Pi-Cheng Chen pi-cheng.c...@linaro.org
+ *
+ * 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
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clk.h
+#include linux/cpu.h
+#include linux/cpu_cooling.h
+#include linux/cpufreq.h
+#include linux/cpumask.h
+#include linux/of.h
+#include linux/platform_device.h
+#include linux/pm_opp.h
+#include linux/regulator/consumer.h
+#include linux/slab.h
+#include linux/thermal.h
+
+#define MIN_VOLT_SHIFT (10)
+#define MAX_VOLT_SHIFT (20)
+#define MAX_VOLT_LIMIT (115)
+#define VOLT_TOL (1)
+
+/*
+ * The struct mtk_cpu_dvfs_info holds necessary information for doing CPU DVFS
+ * on each CPU power/clock domain of Mediatek SoCs. Each CPU cluster in
+ * Mediatek SoCs has two voltage inputs, Vproc and Vsram. In some cases the two
+ * voltage inputs need to be controlled under a hardware limitation:
+ * 100mV Vsram - Vproc 200mV
+ *
+ * When scaling the clock frequency of a CPU clock domain, the clock source
+ * needs to be switched to another stable PLL clock temporarily until
+ * the original PLL becomes stable at target frequency.
+ */
+struct mtk_cpu_dvfs_info {
+ struct device *cpu_dev;
+ struct regulator *proc_reg;
+ struct regulator *sram_reg;
+ struct clk *cpu_clk;
+ struct clk *inter_clk;
+ struct thermal_cooling_device *cdev;
+ int intermediate_voltage;
+ bool need_voltage_tracking;
+};
+
+static int mtk_cpufreq_voltage_tracking(struct mtk_cpu_dvfs_info *info,
+ int new_vproc)
+{
+ struct regulator *proc_reg = info-proc_reg;
+ struct regulator *sram_reg = info-sram_reg;
+ int old_vproc, old_vsram, new_vsram, vsram, vproc, ret;
+
+ old_vproc = regulator_get_voltage(proc_reg);
+ old_vsram = regulator_get_voltage(sram_reg);
+ /* Vsram should not exceed the maximum allowed voltage of
[RESEND PATCH 3/3 v6] arm64: dts: mt8173: mt8173-evb: Add mt8173 cpufreq driver support
This patch adds the required properties in device tree to enable MT8173
cpufreq driver.
Signed-off-by: Pi-Cheng Chen pi-cheng.c...@linaro.org
Acked-by: Viresh Kumar viresh.ku...@linaro.org
---
It is based on the top of MT8173 SoC maintainer's tree:
https://github.com/mbgg/linux-mediatek.git v4.2-next/arm64
commit id: e26945245e414eff42ee1ffeaedf198911bf1d77
---
arch/arm64/boot/dts/mediatek/mt8173-evb.dts | 18
arch/arm64/boot/dts/mediatek/mt8173.dtsi| 64 +
2 files changed, 82 insertions(+)
diff --git a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
index dc4a3e2..ddb1dc1 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
+++ b/arch/arm64/boot/dts/mediatek/mt8173-evb.dts
@@ -261,6 +261,24 @@
};
};
+cpu0 {
+ proc-supply = mt6397_vpca15_reg;
+};
+
+cpu1 {
+ proc-supply = mt6397_vpca15_reg;
+};
+
+cpu2 {
+ proc-supply = da9211_vcpu_reg;
+ sram-supply = mt6397_vsramca7_reg;
+};
+
+cpu3 {
+ proc-supply = da9211_vcpu_reg;
+ sram-supply = mt6397_vsramca7_reg;
+};
+
uart0 {
status = okay;
};
diff --git a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
index 359b8b6..47a443d 100644
--- a/arch/arm64/boot/dts/mediatek/mt8173.dtsi
+++ b/arch/arm64/boot/dts/mediatek/mt8173.dtsi
@@ -53,6 +53,22 @@
reg = 0x000;
enable-method = psci;
cpu-idle-states = CPU_SLEEP_0;
+ clocks = infracfg CLK_INFRA_CA53SEL,
+apmixedsys CLK_APMIXED_MAINPLL;
+ clock-names = cpu, intermediate;
+ operating-points =
+ 507000 859000
+ 702000 908000
+ 1001000 983000
+ 1105000 1009000
+ 1183000 1028000
+ 1404000 1083000
+ 1508000 1109000
+ 1573000 1125000
+ ;
+ #cooling-cells = 2;
+ #cooling-min-level = 0;
+ #cooling-max-level = 7;
};
cpu1: cpu@1 {
@@ -61,6 +77,22 @@
reg = 0x001;
enable-method = psci;
cpu-idle-states = CPU_SLEEP_0;
+ clocks = infracfg CLK_INFRA_CA53SEL,
+apmixedsys CLK_APMIXED_MAINPLL;
+ clock-names = cpu, intermediate;
+ operating-points =
+ 507000 859000
+ 702000 908000
+ 1001000 983000
+ 1105000 1009000
+ 1183000 1028000
+ 1404000 1083000
+ 1508000 1109000
+ 1573000 1125000
+ ;
+ #cooling-cells = 2;
+ #cooling-min-level = 0;
+ #cooling-max-level = 7;
};
cpu2: cpu@100 {
@@ -69,6 +101,22 @@
reg = 0x100;
enable-method = psci;
cpu-idle-states = CPU_SLEEP_0;
+ clocks = infracfg CLK_INFRA_CA57SEL,
+apmixedsys CLK_APMIXED_MAINPLL;
+ clock-names = cpu, intermediate;
+ operating-points =
+ 507000 828000
+ 702000 867000
+ 1001000 927000
+ 1209000 968000
+ 1404000 1007000
+ 1612000 1049000
+ 1807000 1089000
+ 1989000 1125000
+ ;
+ #cooling-cells = 2;
+ #cooling-min-level = 0;
+ #cooling-max-level = 7;
};
cpu3: cpu@101 {
@@ -77,6 +125,22 @@
reg = 0x101;
enable-method = psci;
cpu-idle-states = CPU_SLEEP_0;
+ clocks = infracfg CLK_INFRA_CA57SEL,
+apmixedsys CLK_APMIXED_MAINPLL;
+ clock-names = cpu, intermediate;
+ operating-points =
+ 507000 828000
+ 702000 867000
+ 1001000 927000
+ 1209000 968000
+ 1404000 1007000
+ 1612000 1049000
+
[RESEND PATCH 1/3 v6] dt-bindings: mediatek: Add MT8173 CPU DVFS clock bindings
This patch adds the clock and regulator consumer properties part of
document for CPU DVFS clocks on Mediatek MT8173 SoC.
Signed-off-by: Pi-Cheng Chen pi-cheng.c...@linaro.org
Acked-by: Michael Turquette mturque...@baylibre.com
Acked-by: Viresh Kumar viresh.ku...@linaro.org
---
.../devicetree/bindings/clock/mt8173-cpu-dvfs.txt | 83 ++
1 file changed, 83 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/mt8173-cpu-dvfs.txt
diff --git a/Documentation/devicetree/bindings/clock/mt8173-cpu-dvfs.txt
b/Documentation/devicetree/bindings/clock/mt8173-cpu-dvfs.txt
new file mode 100644
index 000..52b457c
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/mt8173-cpu-dvfs.txt
@@ -0,0 +1,83 @@
+Device Tree Clock bindins for CPU DVFS of Mediatek MT8173 SoC
+
+Required properties:
+- clocks: A list of phandle + clock-specifier pairs for the clocks listed in
clock names.
+- clock-names: Should contain the following:
+ cpu - The multiplexer for clock input of CPU cluster.
+ intermediate - A parent of cpu clock which is used as
intermediate clock
+ source (usually MAINPLL) when the original CPU PLL is
under
+ transition and not stable yet.
+ Please refer to
Documentation/devicetree/bindings/clk/clock-bindings.txt for
+ generic clock consumer properties.
+- proc-supply: Regulator for Vproc of CPU cluster.
+
+Optional properties:
+- sram-supply: Regulator for Vsram of CPU cluster. When present, the cpufreq
driver
+ needs to do voltage tracking to step by step scale up/down
Vproc and
+ Vsram to fit SoC specific needs. When absent, the voltage scaling
+ flow is handled by hardware, hence no software voltage
tracking is
+ needed.
+
+Example:
+
+ cpu0: cpu@0 {
+ device_type = cpu;
+ compatible = arm,cortex-a53;
+ reg = 0x000;
+ enable-method = psci;
+ cpu-idle-states = CPU_SLEEP_0;
+ clocks = infracfg CLK_INFRA_CA53SEL,
+apmixedsys CLK_APMIXED_MAINPLL;
+ clock-names = cpu, intermediate;
+ };
+
+ cpu1: cpu@1 {
+ device_type = cpu;
+ compatible = arm,cortex-a53;
+ reg = 0x001;
+ enable-method = psci;
+ cpu-idle-states = CPU_SLEEP_0;
+ clocks = infracfg CLK_INFRA_CA53SEL,
+apmixedsys CLK_APMIXED_MAINPLL;
+ clock-names = cpu, intermediate;
+ };
+
+ cpu2: cpu@100 {
+ device_type = cpu;
+ compatible = arm,cortex-a57;
+ reg = 0x100;
+ enable-method = psci;
+ cpu-idle-states = CPU_SLEEP_0;
+ clocks = infracfg CLK_INFRA_CA57SEL,
+apmixedsys CLK_APMIXED_MAINPLL;
+ clock-names = cpu, intermediate;
+ };
+
+ cpu3: cpu@101 {
+ device_type = cpu;
+ compatible = arm,cortex-a57;
+ reg = 0x101;
+ enable-method = psci;
+ cpu-idle-states = CPU_SLEEP_0;
+ clocks = infracfg CLK_INFRA_CA57SEL,
+apmixedsys CLK_APMIXED_MAINPLL;
+ clock-names = cpu, intermediate;
+ };
+
+ cpu0 {
+ proc-supply = mt6397_vpca15_reg;
+ };
+
+ cpu1 {
+ proc-supply = mt6397_vpca15_reg;
+ };
+
+ cpu2 {
+ proc-supply = da9211_vcpu_reg;
+ sram-supply = mt6397_vsramca7_reg;
+ };
+
+ cpu3 {
+ proc-supply = da9211_vcpu_reg;
+ sram-supply = mt6397_vsramca7_reg;
+ };
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2] perf: x86: Improve accuracy of perf/sched clock
On Mon, Aug 17, 2015 at 10:34:03AM +0300, Adrian Hunter wrote: On 29/07/15 00:14, Adrian Hunter wrote: When TSC is stable perf/sched clock is based on it. However the conversion from cycles to nanoseconds is not as accurate as it could be. Because CYC2NS_SCALE_FACTOR is 10, the accuracy is +/- 1/2048 The change is to calculate the maximum shift that results in a multiplier that is still a 32-bit number. For example all frequencies over 1 GHz will have a shift of 32, making the accuracy of the conversion +/- 1/(2^33) Signed-off-by: Adrian Hunter adrian.hun...@intel.com Is this OK? Yes I think so, sorry I got backlogged with preparation for Seattle. Thomas, if you see this, could you merge with my ACK on, otherwise I'll queue it the normal route once I'm back. -- 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] PCI: PCI_RCAR_GEN2 and PCI_RCAR_GEN2_PCIE should depend on ARM
Hi Phil,
On Mon, Aug 17, 2015 at 12:23 PM, Phil Edworthy
phil.edwor...@renesas.com wrote:
On 11 August 2015 13:43, Geert wrote:
On arm64/shmobile:
drivers/pci/host/pci-rcar-gen2.c: In function 'rcar_pci_cfg_base':
drivers/pci/host/pci-rcar-gen2.c:112:34: error: dereferencing pointer to
incomplete type
struct rcar_pci_priv *priv = sys-private_data;
^
and
drivers/pci/host/pcie-rcar.c:138:52: warning: 'struct pci_sys_data'
declared
inside parameter list
static inline struct rcar_pcie *sys_to_pcie(struct pci_sys_data *sys)
^
pci_sys_data exists on ARM only, hence these drivers should depend on
ARM unconditionally.
Since these drivers should also be used for R-Car Gen3, I assume someone will
have to fix the problem in the same way the designware pci driver is being
modified.
Please see
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/353421.html
Yes, that would be the correct long-term solution.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
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/1] add-ZTE-pid
On Sun, Aug 02, 2015 at 08:41:48PM -0700, Liu.Zhao wrote:
Make sure to always include a commit message.
Also change you Subject (patch summary) to something more descriptive
using the following format:
USB: option: add ZTE PIDs
Signed-off-by: Liu.Zhao lzsos...@163.com
---
drivers/usb/serial/option.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
index f0c0c53..6996308 100644
--- a/drivers/usb/serial/option.c
+++ b/drivers/usb/serial/option.c
@@ -285,6 +285,10 @@ static void option_instat_callback(struct urb *urb);
#define ZTE_PRODUCT_MC2718 0xffe8
#define ZTE_PRODUCT_AD3812 0xffeb
#define ZTE_PRODUCT_MC2716 0xffed
+#define ZTE_PRODUCT_ZM8620_X 0x0396
+#define ZTE_PRODUCT_ME3620_X 0x1432
+#define ZTE_PRODUCT_ME3620_L 0x1433
+#define ZTE_PRODUCT_ME3620_MBIM 0x0426
I already asked you to try to keep these sorted according to PID (e.g.
add them sorted before ZTE_PRODUCT_AC2726).
#define BENQ_VENDOR_ID 0x04a5
#define BENQ_PRODUCT_H10 0x4068
@@ -544,6 +548,23 @@ static const struct option_blacklist_info
zte_mc2716_z_blacklist = {
.sendsetup = BIT(1) | BIT(2) | BIT(3),
};
+static const struct option_blacklist_info zte_zm8620_x_blacklist = {
+ .reserved = BIT(3) | BIT(4) | BIT(5),
+};
+
+static const struct option_blacklist_info zte_me3620_x_blacklist = {
+ .reserved = BIT(3) | BIT(4) | BIT(5),
+};
+
+static const struct option_blacklist_info zte_me3620_l_blacklist = {
+ .reserved = BIT(3) | BIT(4) | BIT(5),
+};
+
+static const struct option_blacklist_info zte_me3620_mbim_blacklist = {
+ .reserved = BIT(2) | BIT(3) | BIT(4),
+};
I also asked you to consider reusing the blacklist structs for related
devices (e.g. zte_me3620_xl).
Please keep these new structs sorted by symbol name as well.
+
+
Remove the stray newline.
static const struct option_blacklist_info huawei_cdc12_blacklist = {
.reserved = BIT(1) | BIT(2),
};
@@ -1592,6 +1613,14 @@ static const struct usb_device_id option_ids[] = {
{ USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x02, 0x01) },
{ USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x02, 0x05) },
{ USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0xff, 0x86, 0x10) },
+ { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ZM8620_X),
+ .driver_info = (kernel_ulong_t)zte_zm8620_x_blacklist },
+ { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ME3620_X),
+ .driver_info = (kernel_ulong_t)zte_me3620_x_blacklist },
+ { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ME3620_L),
+ .driver_info = (kernel_ulong_t)zte_me3620_l_blacklist },
+ { USB_DEVICE(ZTE_VENDOR_ID, ZTE_PRODUCT_ME3620_MBIM),
+ .driver_info = (kernel_ulong_t)zte_me3620_mbim_blacklist },
And try to keep these entries sorted on symbol names as well (e.g. add
them sorted after ZTE_PRODUCT_MC2716).
{ USB_DEVICE(BENQ_VENDOR_ID, BENQ_PRODUCT_H10) },
{ USB_DEVICE(DLINK_VENDOR_ID, DLINK_PRODUCT_DWM_652) },
Otherwise the patch is now on the right format.
Could you fix up the above and resend?
Please include a [PATCH v3]-prefix in you subject when resending.
Thanks,
Johan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] x86 fixes
On 08/17/2015 10:01 AM, Ingo Molnar wrote: (Sorry about the late reply, wasn't around on the weekend.) * Linus Torvalds torva...@linux-foundation.org wrote: Now that said, I doubt anybody cares. Since we don't support the original 80386, the only way to ever trigger FP emulation is by having a 486SX or possibly a couple of even rarer clone chips. [...] Yeah. So when I re-wrote the FPU code I tried to test math-emu by booting with 'no387': it turned out that ever since the XSAVE code got merged upstream, math-emu oopsed reliably during bootup with a NULL reference, because it wasn't updated to the dynamic allocation logic in: 61c4628b5386 (x86, fpu: split FPU state from task struct - v5) That was 6 years ago, so anything v2.6.26 and later probably has 100% non-working math-emu. So when I re-introduced static allocations math-emu started working again, to a limited degree: on a modern distro, trying to boot /bin/bash I got a prompt, but various programs would segfault. I did not investigate it any deeper, I suppose the FPU emulation does not go far enough for modern user-space, or maybe it has more bugs. So in reality nobody has cared about x86 math-emu in the last 6 years Well... there is this completely crazy x86 javascript emulator by Fabrice Bellard: http://bellard.org/jslinux/tech.html The CPU is close to a 486 compatible x86 without FPU. The lack of FPU is not a problem when running Linux as Operating System because it contains a FPU emulator. I have it running linux 2.6.20 and busybox here: http://busybox.net/live_bbox/live_bbox.html (or rather, *you* will have it running linux 2.6.20 inside your browser, after you click on that link) -- 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/2] powerpc32: optimise csum_partial() loop
Le 17/08/2015 12:56, leroy christophe a écrit : Le 07/08/2015 01:25, Segher Boessenkool a écrit : On Thu, Aug 06, 2015 at 05:45:45PM -0500, Scott Wood wrote: If this makes performance non-negligibly worse on other 32-bit chips, and is an important improvement on 8xx, then we can use an ifdef since 8xx already requires its own kernel build. I'd prefer to see a benchmark showing that it actually does make things worse on those chips, though. And I'd like to see a benchmark that shows it *does not* hurt performance on most chips, and does improve things on 8xx, and by how much. But it isn't *me* who has to show that, it is not my patch. Ok, following this discussion I made some additional measurement and it looks like: * There is almost no change on the 885 * There is a non negligeable degradation on the 8323 (19.5 tb ticks instead of 15.3) Thanks for pointing this out, I think my patch is therefore not good. Oops, I was talking about my other past, the one that was to optimise ip_csum_fast. I still have to measure csum_partial Christophe -- 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/10] mm, page_alloc: Remove unnecessary taking of a seqlock when cpusets are disabled
On Wed, Aug 12, 2015 at 05:16:50PM -0700, David Rientjes wrote:
On Wed, 12 Aug 2015, Mel Gorman wrote:
There is a seqcounter that protects against spurious allocation failures
when a task is changing the allowed nodes in a cpuset. There is no need
to check the seqcounter until a cpuset exists.
Signed-off-by: Mel Gorman mgor...@techsingularity.net
Acked-by: David Rientjes rient...@google.com
Acked-by: Vlastimil Babka vba...@suse.cz
---
include/linux/cpuset.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/linux/cpuset.h b/include/linux/cpuset.h
index 1b357997cac5..6eb27cb480b7 100644
--- a/include/linux/cpuset.h
+++ b/include/linux/cpuset.h
@@ -104,6 +104,9 @@ extern void cpuset_print_task_mems_allowed(struct
task_struct *p);
*/
static inline unsigned int read_mems_allowed_begin(void)
{
+ if (!cpusets_enabled())
+ return 0;
+
return read_seqcount_begin(current-mems_allowed_seq);
}
@@ -115,6 +118,9 @@ static inline unsigned int read_mems_allowed_begin(void)
*/
static inline bool read_mems_allowed_retry(unsigned int seq)
{
+ if (!cpusets_enabled())
+ return false;
+
return read_seqcount_retry(current-mems_allowed_seq, seq);
}
This patch is an obvious improvement, but I think it's also possible to
change this to be
if (nr_cpusets() = 1)
return false;
and likewise in the existing cpusets_enabled() check in
get_page_from_freelist(). A root cpuset may not exclude mems on the
system so, even if mounted, there's no need to check or be worried about
concurrent change when there is only one cpuset.
Good idea. I'll make this a separate patch on top and rename cpuset_enabled
to cpuset_mems_enabled to be clear about what it's checking.
Thanks.
--
Mel Gorman
SUSE Labs
--
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] drm: panel: simple: add QiaoDian qd43003c0-40
On Mon, Aug 17, 2015 at 12:57:24PM +0200, Alexandre Belloni wrote: On 17/08/2015 at 12:09:14 +0200, Thierry Reding wrote : On Sat, Aug 01, 2015 at 12:44:31AM +0200, Alexandre Belloni wrote: From: Josh Wu josh...@atmel.com The QiaoDian Xianshi QD43003C0-40 is a 43 TFT LCD panel. Timings from the OTA5180A document, ver 0.9, section 10.1.1: http://www.orientdisplay.com/pdf/OTA5180A.pdf Signed-off-by: Josh Wu josh...@atmel.com Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com --- .../devicetree/bindings/panel/qd,qd43003c0-40.txt | 7 ++ drivers/gpu/drm/panel/panel-simple.c | 26 ++ 2 files changed, 33 insertions(+) create mode 100644 Documentation/devicetree/bindings/panel/qd,qd43003c0-40.txt You didn't run this through scripts/get_maintainer.pl, did you? It would also help to use the standard prefix (drm/panel: ) because I end up filtering for that occasionally in case somebody didn't Cc me on panel patches. I'm pretty sure I did as you were the only one in the To: field. Maybe you want to check your spam filter. Looking again, I see that you did indeed. Not sure what I was looking at before. I apologize. Thierry signature.asc Description: PGP signature
[RESEND PATCH v5] clk: mediatek: Export CPU mux clocks for CPU frequency control
From: pi-cheng.chen pi-cheng.c...@linaro.org
This patch adds CPU mux clocks which are used by Mediatek cpufreq driver
for intermediate clock source switching.
Signed-off-by: Pi-Cheng Chen pi-cheng.c...@linaro.org
Reviewed-by: Daniel Kurtz djku...@chromium.org
---
Changes in v5:
- Replace __initdata with __initconst to fix compiling error
Changes in v4:
- Fix some minor issues for v3
- Rebase to the patch that adds 13mhz clock for MT8173[1]
Changes in v3:
- Rebase to 4.2-rc1
- Fix some issues of v2
Changes in v2:
- Remove use of .determine_rate callback
[1] http://patchwork.kernerl.xyz/patch/6777041/
---
drivers/clk/mediatek/Makefile | 2 +-
drivers/clk/mediatek/clk-cpumux.c | 127 +
drivers/clk/mediatek/clk-cpumux.h | 22 ++
drivers/clk/mediatek/clk-mt8173.c | 23 ++
include/dt-bindings/clock/mt8173-clk.h | 4 +-
5 files changed, 176 insertions(+), 2 deletions(-)
create mode 100644 drivers/clk/mediatek/clk-cpumux.c
create mode 100644 drivers/clk/mediatek/clk-cpumux.h
diff --git a/drivers/clk/mediatek/Makefile b/drivers/clk/mediatek/Makefile
index 8e4b2a4..299917a 100644
--- a/drivers/clk/mediatek/Makefile
+++ b/drivers/clk/mediatek/Makefile
@@ -1,4 +1,4 @@
-obj-y += clk-mtk.o clk-pll.o clk-gate.o
+obj-y += clk-mtk.o clk-pll.o clk-gate.o clk-cpumux.o
obj-$(CONFIG_RESET_CONTROLLER) += reset.o
obj-y += clk-mt8135.o
obj-y += clk-mt8173.o
diff --git a/drivers/clk/mediatek/clk-cpumux.c
b/drivers/clk/mediatek/clk-cpumux.c
new file mode 100644
index 000..fb04fe1
--- /dev/null
+++ b/drivers/clk/mediatek/clk-cpumux.c
@@ -0,0 +1,127 @@
+/*
+ * Copyright (c) 2015 Linaro Ltd.
+ * Author: Pi-Cheng Chen pi-cheng.c...@linaro.org
+ *
+ * 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
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/clk-provider.h
+#include linux/mfd/syscon.h
+#include linux/slab.h
+
+#include clk-mtk.h
+#include clk-cpumux.h
+
+struct mtk_clk_cpumux {
+ struct clk_hw hw;
+ struct regmap *regmap;
+ u32 reg;
+ u32 mask;
+ u8 shift;
+};
+
+static inline struct mtk_clk_cpumux *to_clk_mux(struct clk_hw *_hw)
+{
+ return container_of(_hw, struct mtk_clk_cpumux, hw);
+}
+
+static u8 clk_cpumux_get_parent(struct clk_hw *hw)
+{
+ struct mtk_clk_cpumux *mux = to_clk_mux(hw);
+ int num_parents = __clk_get_num_parents(hw-clk);
+ unsigned int val;
+
+ regmap_read(mux-regmap, mux-reg, val);
+
+ val = mux-shift;
+ val = mux-mask;
+
+ if (val = num_parents)
+ return -EINVAL;
+
+ return val;
+}
+
+static int clk_cpumux_set_parent(struct clk_hw *hw, u8 index)
+{
+ struct mtk_clk_cpumux *mux = to_clk_mux(hw);
+ u32 mask, val;
+
+ val = index mux-shift;
+ mask = mux-mask mux-shift;
+
+ return regmap_update_bits(mux-regmap, mux-reg, mask, val);
+}
+
+static const struct clk_ops clk_cpumux_ops = {
+ .get_parent = clk_cpumux_get_parent,
+ .set_parent = clk_cpumux_set_parent,
+};
+
+static struct clk __init *mtk_clk_register_cpumux(const struct mtk_composite
*mux,
+ struct regmap *regmap)
+{
+ struct mtk_clk_cpumux *cpumux;
+ struct clk *clk;
+ struct clk_init_data init;
+
+ cpumux = kzalloc(sizeof(*cpumux), GFP_KERNEL);
+ if (!cpumux)
+ return ERR_PTR(-ENOMEM);
+
+ init.name = mux-name;
+ init.ops = clk_cpumux_ops;
+ init.parent_names = mux-parent_names;
+ init.num_parents = mux-num_parents;
+ init.flags = mux-flags;
+
+ cpumux-reg = mux-mux_reg;
+ cpumux-shift = mux-mux_shift;
+ cpumux-mask = BIT(mux-mux_width) - 1;
+ cpumux-regmap = regmap;
+ cpumux-hw.init = init;
+
+ clk = clk_register(NULL, cpumux-hw);
+ if (IS_ERR(clk))
+ kfree(cpumux);
+
+ return clk;
+}
+
+int __init mtk_clk_register_cpumuxes(struct device_node *node,
+ const struct mtk_composite *clks, int num,
+ struct clk_onecell_data *clk_data)
+{
+ int i;
+ struct clk *clk;
+ struct regmap *regmap;
+
+ regmap = syscon_node_to_regmap(node);
+ if (IS_ERR(regmap)) {
+ pr_err(Cannot find regmap for %s: %ld\n, node-full_name,
+ PTR_ERR(regmap));
+ return PTR_ERR(regmap);
+ }
+
+ for (i = 0; i num; i++) {
+ const struct mtk_composite *mux = clks[i];
+
+ clk = mtk_clk_register_cpumux(mux, regmap);
+
Re: [PATCH] gpio/grgpio: fix deadlock in grgpio_irq_unmap()
On Mon, Aug 17, 2015 at 10:23 AM, Alexandre Courbot acour...@nvidia.com wrote: As reported by Alexey Khoroshilov: grgpio_irq_unmap() code looks quite suspicious regarding usage of priv-bgc.lock spinlock. It locks the spinlock in line 310: spin_lock_irqsave(priv-bgc.lock, flags); and then it can call grgpio_set_imask() in line 317: grgpio_set_imask(priv, i, 0); But grgpio_set_imask() unconditionally locks the spinlock by itself. Fix this by moving the spinlock acquisition outside of grgpio_set_imask(). Found by Linux Driver Verification project (linuxtesting.org). Reported-by: Alexey Khoroshilov khoroshi...@ispras.ru Signed-off-by: Alexandre Courbot acour...@nvidia.com CC: Alexey Khoroshilov khoroshi...@ispras.ru CC: Andreas Larsson andr...@gaisler.com Patch applied. Yours, Linus Walleij -- 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] Staging: gdm72xx: usb_ids: fix a macro coding style error
On Fri, Aug 14, 2015 at 01:08:32PM -0400, Raphaël Beamonte wrote: Fix a macro with complex value coding style error. This patch description is too vague. regards, dan carpenter -- 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: [RFCv5, 18/46] arm: topology: Define TC2 energy and provide it to the scheduler
Hi Morten,
On Tue, Jul 07, 2015 at 07:24:01PM +0100, Morten Rasmussen wrote:
From: Dietmar Eggemann dietmar.eggem...@arm.com
This patch is only here to be able to test provisioning of energy related
data from an arch topology shim layer to the scheduler. Since there is no
code today which deals with extracting energy related data from the dtb or
acpi, and process it in the topology shim layer, the content of the
sched_group_energy structures as well as the idle_state and capacity_state
arrays are hard-coded here.
This patch defines the sched_group_energy structure as well as the
idle_state and capacity_state array for the cluster (relates to sched
groups (sgs) in DIE sched domain level) and for the core (relates to sgs
in MC sd level) for a Cortex A7 as well as for a Cortex A15.
It further provides related implementations of the sched_domain_energy_f
functions (cpu_cluster_energy() and cpu_core_energy()).
To be able to propagate this information from the topology shim layer to
the scheduler, the elements of the arm_topology[] table have been
provisioned with the appropriate sched_domain_energy_f functions.
cc: Russell King li...@arm.linux.org.uk
Signed-off-by: Dietmar Eggemann dietmar.eggem...@arm.com
---
arch/arm/kernel/topology.c | 118 +++--
1 file changed, 115 insertions(+), 3 deletions(-)
diff --git a/arch/arm/kernel/topology.c b/arch/arm/kernel/topology.c
index b35d3e5..bbe20c7 100644
--- a/arch/arm/kernel/topology.c
+++ b/arch/arm/kernel/topology.c
@@ -274,6 +274,119 @@ void store_cpu_topology(unsigned int cpuid)
cpu_topology[cpuid].socket_id, mpidr);
}
+/*
+ * ARM TC2 specific energy cost model data. There are no unit requirements
for
+ * the data. Data can be normalized to any reference point, but the
+ * normalization must be consistent. That is, one bogo-joule/watt must be the
+ * same quantity for all data, but we don't care what it is.
+ */
+static struct idle_state idle_states_cluster_a7[] = {
+ { .power = 25 }, /* WFI */
This state is confused. Is this state corresponding to all CPUs have been
powered off but L2 cache RAM array and SCU are still power on?
+ { .power = 10 }, /* cluster-sleep-l */
Is this status means all CPU and cluster have been powered off, if so
then it will have no power consumption anymore...
+ };
+
+static struct idle_state idle_states_cluster_a15[] = {
+ { .power = 70 }, /* WFI */
+ { .power = 25 }, /* cluster-sleep-b */
+ };
+
+static struct capacity_state cap_states_cluster_a7[] = {
+ /* Cluster only power */
+ { .cap = 150, .power = 2967, }, /* 350 MHz */
For cluster level's capacity, does it mean need run benchmark on all
CPUs within cluster?
+ { .cap = 172, .power = 2792, }, /* 400 MHz */
+ { .cap = 215, .power = 2810, }, /* 500 MHz */
+ { .cap = 258, .power = 2815, }, /* 600 MHz */
+ { .cap = 301, .power = 2919, }, /* 700 MHz */
+ { .cap = 344, .power = 2847, }, /* 800 MHz */
+ { .cap = 387, .power = 3917, }, /* 900 MHz */
+ { .cap = 430, .power = 4905, }, /* 1000 MHz */
+ };
+
+static struct capacity_state cap_states_cluster_a15[] = {
+ /* Cluster only power */
+ { .cap = 426, .power = 7920, }, /* 500 MHz */
+ { .cap = 512, .power = 8165, }, /* 600 MHz */
+ { .cap = 597, .power = 8172, }, /* 700 MHz */
+ { .cap = 682, .power = 8195, }, /* 800 MHz */
+ { .cap = 768, .power = 8265, }, /* 900 MHz */
+ { .cap = 853, .power = 8446, }, /* 1000 MHz */
+ { .cap = 938, .power = 11426, }, /* 1100 MHz */
+ { .cap = 1024, .power = 15200, }, /* 1200 MHz */
+ };
+
+static struct sched_group_energy energy_cluster_a7 = {
+ .nr_idle_states = ARRAY_SIZE(idle_states_cluster_a7),
+ .idle_states= idle_states_cluster_a7,
+ .nr_cap_states = ARRAY_SIZE(cap_states_cluster_a7),
+ .cap_states = cap_states_cluster_a7,
+};
+
+static struct sched_group_energy energy_cluster_a15 = {
+ .nr_idle_states = ARRAY_SIZE(idle_states_cluster_a15),
+ .idle_states= idle_states_cluster_a15,
+ .nr_cap_states = ARRAY_SIZE(cap_states_cluster_a15),
+ .cap_states = cap_states_cluster_a15,
+};
+
+static struct idle_state idle_states_core_a7[] = {
+ { .power = 0 }, /* WFI */
Should have two idle states for CPU level (WFI and CPU's power off)?
+ };
+
+static struct idle_state idle_states_core_a15[] = {
+ { .power = 0 }, /* WFI */
+ };
+
+static struct capacity_state cap_states_core_a7[] = {
+ /* Power per cpu */
+ { .cap = 150, .power = 187, }, /* 350 MHz */
+ { .cap = 172, .power = 275, }, /* 400 MHz */
+ { .cap = 215, .power = 334, }, /* 500 MHz */
+ { .cap = 258, .power = 407, }, /* 600 MHz */
+ { .cap = 301, .power = 447, }, /* 700 MHz */
+ {
RE: [PATCH] PCI: PCI_RCAR_GEN2 and PCI_RCAR_GEN2_PCIE should depend on ARM
Hi Geert, On 11 August 2015 13:43, Geert wrote: On arm64/shmobile: drivers/pci/host/pci-rcar-gen2.c: In function 'rcar_pci_cfg_base': drivers/pci/host/pci-rcar-gen2.c:112:34: error: dereferencing pointer to incomplete type struct rcar_pci_priv *priv = sys-private_data; ^ and drivers/pci/host/pcie-rcar.c:138:52: warning: 'struct pci_sys_data' declared inside parameter list static inline struct rcar_pcie *sys_to_pcie(struct pci_sys_data *sys) ^ pci_sys_data exists on ARM only, hence these drivers should depend on ARM unconditionally. Since these drivers should also be used for R-Car Gen3, I assume someone will have to fix the problem in the same way the designware pci driver is being modified. Please see http://lists.infradead.org/pipermail/linux-arm-kernel/2015-July/353421.html Of course, as a quick fix for the compile test failure, this is fine. Best regards Phil Signed-off-by: Geert Uytterhoeven geert+rene...@glider.be --- drivers/pci/host/Kconfig | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig index 48b5b3058d9d09eb..e94392560842be0a 100644 --- a/drivers/pci/host/Kconfig +++ b/drivers/pci/host/Kconfig @@ -39,7 +39,8 @@ config PCI_TEGRA config PCI_RCAR_GEN2 bool Renesas R-Car Gen2 Internal PCI controller - depends on ARCH_SHMOBILE || (ARM COMPILE_TEST) + depends on ARM + depends on ARCH_SHMOBILE || COMPILE_TEST help Say Y here if you want internal PCI support on R-Car Gen2 SoC. There are 3 internal PCI controllers available with a single @@ -47,7 +48,8 @@ config PCI_RCAR_GEN2 config PCI_RCAR_GEN2_PCIE bool Renesas R-Car PCIe controller - depends on ARCH_SHMOBILE || (ARM COMPILE_TEST) + depends on ARM + depends on ARCH_SHMOBILE || COMPILE_TEST help Say Y here if you want PCIe controller support on R-Car Gen2 SoCs. -- 1.9.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ASoC: mediatek: Remove AIF widgets for backend DAIs
DAPM core already creates widgets for DAIs. It is not necessary
to declare them by SND_SOC_DAPM_AIF_IN/SND_SOC_DAPM_AIF_OUT.
Furthermore, original codes use backend DAI's stream name to be the AIF
widget name. It causes the same widget to be created twice, and after
commit 92fa12426741 (ASoC: dapm: Add new widgets to the end of the
widget list) the first created widget (by snd_soc_dapm_new_controls)
is used, not the 2nd created one (by snd_soc_dapm_new_dai_widgets),
so audio path is broken.
Signed-off-by: Koro Chen koro.c...@mediatek.com
---
sound/soc/mediatek/mtk-afe-pcm.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/sound/soc/mediatek/mtk-afe-pcm.c b/sound/soc/mediatek/mtk-afe-pcm.c
index 55471ee..d190fe0 100644
--- a/sound/soc/mediatek/mtk-afe-pcm.c
+++ b/sound/soc/mediatek/mtk-afe-pcm.c
@@ -897,10 +897,6 @@ static const struct snd_kcontrol_new mtk_afe_o10_mix[] = {
};
static const struct snd_soc_dapm_widget mtk_afe_pcm_widgets[] = {
- /* Backend DAIs */
- SND_SOC_DAPM_AIF_IN(I2S Capture, NULL, 0, SND_SOC_NOPM, 0, 0),
- SND_SOC_DAPM_AIF_OUT(I2S Playback, NULL, 0, SND_SOC_NOPM, 0, 0),
-
/* inter-connections */
SND_SOC_DAPM_MIXER(I05, SND_SOC_NOPM, 0, 0, NULL, 0),
SND_SOC_DAPM_MIXER(I06, SND_SOC_NOPM, 0, 0, NULL, 0),
@@ -932,11 +928,6 @@ static const struct snd_soc_dapm_route
mtk_afe_pcm_routes[] = {
{ O10, I18 Switch, I18 },
};
-static const struct snd_soc_dapm_widget mtk_afe_hdmi_widgets[] = {
- /* Backend DAIs */
- SND_SOC_DAPM_AIF_OUT(HDMIO Playback, NULL, 0, SND_SOC_NOPM, 0, 0),
-};
-
static const struct snd_soc_dapm_route mtk_afe_hdmi_routes[] = {
{HDMIO Playback, NULL, HDMI},
};
@@ -951,8 +942,6 @@ static const struct snd_soc_component_driver
mtk_afe_pcm_dai_component = {
static const struct snd_soc_component_driver mtk_afe_hdmi_dai_component = {
.name = mtk-afe-hdmi-dai,
- .dapm_widgets = mtk_afe_hdmi_widgets,
- .num_dapm_widgets = ARRAY_SIZE(mtk_afe_hdmi_widgets),
.dapm_routes = mtk_afe_hdmi_routes,
.num_dapm_routes = ARRAY_SIZE(mtk_afe_hdmi_routes),
};
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: hfi1: Kconfig: remove 'CONFIG_' prefix
Remove the 'CONFIG_' prefix of the Kconfig options PRESCAN_RXQ and
SDMA_VERBOSITY in Kconfig. Such prefix in Kconfig requires a double
'CONFIG_CONFIG_' prefix in Make and CPP syntax.
Since both options are referenced in the hfi1 source code as
CONFIG_{PRESCAN_RXQ, SDMA_VERBOSITY} the referencing #ifdef's can now be
compiled.
Signed-off-by: Valentin Rothberg valentinrothb...@gmail.com
---
Note that this issue was present since the driver's config files have
been added by commit 8214d07e6f21 (IB/hfi1: add driver make/config
files). This change does not introduce any build issues, but I cannot
test it.
I detected this issues with scripts/checkkconfigsymbols.py by diffing
next-20150814..next-20150817
drivers/staging/hfi1/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/hfi1/Kconfig b/drivers/staging/hfi1/Kconfig
index 87a385a02cba..fd25078ee923 100644
--- a/drivers/staging/hfi1/Kconfig
+++ b/drivers/staging/hfi1/Kconfig
@@ -18,14 +18,14 @@ config HFI1_VERBS_31BIT_PSN
---help---
Setting this enables 31 BIT PSN
For verbs RC/UC
-config CONFIG_SDMA_VERBOSITY
+config SDMA_VERBOSITY
bool Config SDMA Verbosity
depends on INFINIBAND_HFI1
default n
---help---
This is a configuration flag to enable verbose
SDMA debug
-config CONFIG_PRESCAN_RXQ
+config PRESCAN_RXQ
bool Enable prescanning of the RX queue for ECNs
depends on INFINIBAND_HFI1
default n
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/3] Introduce usb charger framework to deal with the usb gadget power negotation
On 17 August 2015 at 16:20, Li Jun b47...@freescale.com wrote: On Mon, Aug 17, 2015 at 02:02:08PM +0800, Baolin Wang wrote: On 17 August 2015 at 09:15, Li Jun b47...@freescale.com wrote: On Fri, Aug 14, 2015 at 07:04:56PM +0800, Baolin Wang wrote: On 14 August 2015 at 16:55, Li Jun b47...@freescale.com wrote: Hi Baolin, On Fri, Aug 14, 2015 at 05:47:43PM +0800, Baolin Wang wrote: Currently the Linux kernel does not provide any standard integration of this feature that integrates the USB subsystem with the system power regulation provided by PMICs meaning that either vendors must add this in their kernels or USB gadget devices based on Linux (such as mobile phones) may not behave as they should. Providing a standard framework for doing this in the kernel. Why not add power supply class support into this? Hi Jun, We don't need the power supply class support into the usb charger, I suppose usb charger is also a power supply for the system, we can use power supply class framework for notify mechanism and get/set many attributes(maybe also the current limit), I see those usb charger drivers under ./driver/power/ are designed with power supply supported. I don't think so. The usb charger is rely on the usb gadget, which is not a complete power supply device and it combines the usb and the power supply. Thus we make it into usb gadget system. Thanks. Why it cannot be a complete power supply device? I was thinking this framework can cover it, I have no doubt on putting this framework into gadget system, but still can't understand why we don't need power supply class at all for a usb charger, or you think introduce power supply into usb gadget is not a right direction from code structure point view? We just do not think the usb charger as a real device, which is only used to set the current limitation when the usb charger state is changed detecting by extcon device or usb gadget. So we just need one message to notify the power user to set the current limitation when uab charge is added or removed. I also agree with the power supply framework can cover it, but we don't need to implement it to be another power supply, cause there is a real device as the power supply to deal with the power issue in the system. Thanks. Li Jun Li Jun just introduce the notify mechanism for power to set the current limit when notifying some events from usb charger. Maybe I misunderstand your meanings, please describe it detailedly. Thanks for your comments. Li Jun -- Baolin.wang Best Regards -- Baolin.wang Best Regards -- Baolin.wang Best Regards -- 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 v4 2/5] pci:host: Add Altera PCIe host controller driver
This patch adds the Altera PCIe host controller driver.
Signed-off-by: Ley Foon Tan lf...@altera.com
---
drivers/pci/host/Kconfig | 7 +
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pcie-altera.c | 543 +
3 files changed, 551 insertions(+)
create mode 100644 drivers/pci/host/pcie-altera.c
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 675c2d1..4b4754a 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -145,4 +145,11 @@ config PCIE_IPROC_BCMA
Say Y here if you want to use the Broadcom iProc PCIe controller
through the BCMA bus interface
+config PCIE_ALTERA
+ tristate Altera PCIe controller
+ depends on ARCH_SOCFPGA
+ help
+ Say Y here if you want to enable PCIe controller support for Altera
+ SoCFPGA family of SoCs.
+
endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 140d66f..6954f76 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -17,3 +17,4 @@ obj-$(CONFIG_PCI_VERSATILE) += pci-versatile.o
obj-$(CONFIG_PCIE_IPROC) += pcie-iproc.o
obj-$(CONFIG_PCIE_IPROC_PLATFORM) += pcie-iproc-platform.o
obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
+obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
diff --git a/drivers/pci/host/pcie-altera.c b/drivers/pci/host/pcie-altera.c
new file mode 100644
index 000..130796e
--- /dev/null
+++ b/drivers/pci/host/pcie-altera.c
@@ -0,0 +1,543 @@
+/*
+ * Copyright Altera Corporation (C) 2013-2015. All rights reserved
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+#include linux/delay.h
+#include linux/interrupt.h
+#include linux/irqchip/chained_irq.h
+#include linux/module.h
+#include linux/of_address.h
+#include linux/of_irq.h
+#include linux/of_pci.h
+#include linux/pci.h
+#include linux/platform_device.h
+#include linux/slab.h
+
+#define A2P_ADDR_MAP_LO0 0x1000
+#define A2P_ADDR_MAP_HI0 0x1004
+#define RP_TX_REG0 0x2000
+#define RP_TX_REG1 0x2004
+#define RP_TX_CNTRL0x2008
+#define RP_TX_EOP 0x2
+#define RP_TX_SOP 0x1
+#define RP_RXCPL_STATUS0x2010
+#define RP_RXCPL_EOP 0x2
+#define RP_RXCPL_SOP 0x1
+#define RP_RXCPL_REG0 0x2014
+#define RP_RXCPL_REG1 0x2018
+#define P2A_INT_STATUS 0x3060
+#define P2A_INT_STS_ALL0xF
+#define P2A_INT_ENABLE 0x3070
+#define P2A_INT_ENA_ALL0xF
+#define RP_LTSSM 0x3C64
+#define LTSSM_L0 0xF
+
+/* TLP configuration type 0 and 1 */
+#define TLP_FMTTYPE_CFGRD0 0x04/* Configuration Read Type 0 */
+#define TLP_FMTTYPE_CFGWR0 0x44/* Configuration Write Type 0 */
+#define TLP_FMTTYPE_CFGRD1 0x05/* Configuration Read Type 1 */
+#define TLP_FMTTYPE_CFGWR1 0x45/* Configuration Write Type 1 */
+#define TLP_PAYLOAD_SIZE 0x01
+#define TLP_READ_TAG 0x1D
+#define TLP_WRITE_TAG 0x10
+#define TLP_CFG_DW0(fmttype) (((fmttype) 24) | TLP_PAYLOAD_SIZE)
+#define TLP_CFG_DW1(reqid, tag)(((reqid) 16) | (tag 8) |
0xF)
+#define TLP_CFG_DW2(bus, devfn, offset)\
+ (((bus) 24) | ((devfn) 16) | (offset))
+#define TLP_REQ_ID(bus, devfn) (((bus) 8) | (devfn))
+#define TLP_COMPL_STATUS(hdr) (((hdr) 0xE0) 13)
+#define TLP_HDR_SIZE 3
+#define TLP_LOOP 10
+
+#define INTX_NUM 4
+
+/* Address translation table entry size */
+#define ATT_ENTRY_SIZE 8
+
+#define DWORD_MASK 3
+
+struct altera_pcie {
+ struct platform_device *pdev;
+ struct resource *txs;
+ void __iomem*cra_base;
+ int irq;
+ u8 root_bus_nr;
+ struct irq_domain *irq_domain;
+ struct resource bus_range;
+ struct list_headresources;
+};
+
+struct tlp_rp_regpair_t {
+ u32 ctrl;
+ u32 reg0;
+ u32 reg1;
+};
+
+static void altera_pcie_retrain(struct pci_dev *dev)
+{
+ u16 linkcap,
Re: [RFC PATCH kernel vfio] mm: vfio: Move pages out of CMA before pinning
On 08/17/2015 05:45 PM, Vlastimil Babka wrote: On 08/05/2015 10:08 AM, Alexey Kardashevskiy wrote: This is about VFIO aka PCI passthrough used from QEMU. KVM is irrelevant here. QEMU is a machine emulator. It allocates guest RAM from anonymous memory and these pages are movable which is ok. They may happen to be allocated from the contiguous memory allocation zone (CMA). Which is also ok as long they are movable. However if the guest starts using VFIO (which can be hotplugged into the guest), in most cases it involves DMA which requires guest RAM pages to be pinned and not move once their addresses are programmed to the hardware for DMA. So we end up in a situation when quite many pages in CMA are not movable anymore. And we get bunch of these: [77306.513966] alloc_contig_range: [1f3800, 1f78c4) PFNs busy [77306.514448] alloc_contig_range: [1f3800, 1f78c8) PFNs busy [77306.514927] alloc_contig_range: [1f3800, 1f78cc) PFNs busy IIRC CMA was for mobile devices and their camera/codec drivers and you don't use QEMU on those? What do you need CMA for in your case? I do not want QEMU to get memory from CMA, this is my point. It just happens sometime that the kernel allocates movable pages from there. This is a very rough patch to start the conversation about how to move pages properly. mm/page_alloc.c does this and arch/powerpc/mm/mmu_context_iommu.c exploits it. OK such conversation should probably start by mentioning the VM_PINNED effort by Peter Zijlstra: https://lkml.org/lkml/2014/5/26/345 It's more general approach to dealing with pinned pages, and moving them out of CMA area (and compacting them in general) prior pinning is one of the things that should be done within that framework. And I assume these patches did not go anywhere, right?... Then there's the effort to enable migrating pages other than LRU during compaction (and thus CMA allocation): https://lwn.net/Articles/650864/ I don't know if that would be applicable in your use case, i.e. are the pins for DMA short-lived and can the isolation/migration code wait a bit for the transfer to finish so it can grab them, or something? Pins for DMA are long-lived, pretty much as long as the guest is running. So this compaction is too late. Please do not comment on the style and code placement, this is just to give some context :) Obviously, this does not work well - it manages to migrate only few pages and crashes as it is missing locks/disabling interrupts and I probably should not just remove pages from LRU list (normally, I guess, only these can migrate) and a million of other things. The questions are: - what is the correct way of telling if the page is in CMA? is (get_pageblock_migratetype(page) == MIGRATE_CMA) good enough? Should be. - how to tell MM to move page away? I am calling migrate_pages() with an get_new_page callback which allocates a page with GFP_USER but without GFP_MOVABLE which should allocate new page out of CMA which seems ok but there is a little convern that we might want to add MOVABLE back when VFIO device is unplugged from the guest. Hmm, once the page is allocated, then the migratetype is not tracked anywhere (except in page_owner debug data). But the unmovable allocations might exhaust available unmovable pageblocks and lead to fragmentation. So add MOVABLE back would be too late. Instead we would need to tell the allocator somehow to give us movable page but outside of CMA. It is it movable, why do we care if it is in CMA or not? CMA's own __alloc_contig_migrate_range() avoids this problem by allocating movable pages, but the range has been already page-isolated and thus the allocator won't see the pages there.You obviously can't take this approach and isolate all CMA pageblocks like that. That smells like a new __GFP_FLAG, meh. I understood (more or less) all of it except the __GFP_FLAG - when/what would use it? - do I need to isolate pages by using isolate_migratepages_range, reclaim_clean_pages_from_list like __alloc_contig_migrate_range does? I dropped them for now and the patch uses only @migratepages from the compact_control struct. You don't have to do reclaim_clean_pages_from_list(), but the isolation has to be careful, yeah. The isolation here means the whole CMA zone isolation which I obviously can't take this approach? :) - are there any flags in madvise() to address this (could not locate any relevant)? AFAIK there's no madvise(I_WILL_BE_PINNING_THIS_RANGE) - what else is missing? disabled interrupts? locks? See what isolate_migratepages_block() does. Thanks for the pointers! I'll have a closer look at Peter's patchset. -- 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/
[PATCH v4 1/5] arm: add msi.h to Kbuild
Include asm-generic/msi.h to support CONFIG_GENERIC_MSI_IRQ_DOMAIN. This to fix compilation error: include/linux/msi.h:123:21: fatal error: asm/msi.h: No such file or directory Signed-off-by: Ley Foon Tan lf...@altera.com --- arch/arm/include/asm/Kbuild | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm/include/asm/Kbuild b/arch/arm/include/asm/Kbuild index 83c5019..ddc2761 100644 --- a/arch/arm/include/asm/Kbuild +++ b/arch/arm/include/asm/Kbuild @@ -14,6 +14,7 @@ generic-y += local.h generic-y += local64.h generic-y += mcs_spinlock.h generic-y += msgbuf.h +generic-y += msi.h generic-y += param.h generic-y += parport.h generic-y += poll.h -- 1.8.2.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 v4] pinctrl: mediatek: Implement wake handler and suspend resume
On Mon, Aug 17, 2015 at 3:52 PM, Yingjoe Chen yingjoe.c...@mediatek.com wrote:
On Fri, 2015-08-14 at 16:38 +0800, maoguang.m...@mediatek.com wrote:
From: Maoguang Meng maoguang.m...@mediatek.com
This patch implement irq_set_wake to get who is wakeup source and
setup on suspend resume.
Signed-off-by: Maoguang Meng maoguang.m...@mediatek.com
---
changes since v3:
-add a comment in mtk_eint_chip_read_mask.
-delete ALIGN when allocate eint_offsets.ports.
-fix unrelated change.
changes since v2:
-modify irq_wake to handle irq wakeup source.
-allocate two buffers separately.
-fix some codestyle.
Changes since v1:
-implement irq_wake handler.
---
drivers/pinctrl/mediatek/pinctrl-mt8173.c | 1 +
drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 91
++-
drivers/pinctrl/mediatek/pinctrl-mtk-common.h | 4 ++
3 files changed, 95 insertions(+), 1 deletion(-)
diff --git a/drivers/pinctrl/mediatek/pinctrl-mt8173.c
b/drivers/pinctrl/mediatek/pinctrl-mt8173.c
index d0c811d..ad27184 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mt8173.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mt8173.c
@@ -385,6 +385,7 @@ static struct platform_driver mtk_pinctrl_driver = {
.driver = {
.name = mediatek-mt8173-pinctrl,
.of_match_table = mt8173_pctrl_match,
+ .pm = mtk_eint_pm_ops,
},
};
diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
index ad1ea16..fe34ce9 100644
--- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
+++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
@@ -33,6 +33,7 @@
#include linux/mfd/syscon.h
#include linux/delay.h
#include linux/interrupt.h
+#include linux/pm.h
#include dt-bindings/pinctrl/mt65xx.h
#include ../core.h
@@ -1062,6 +1063,77 @@ static int mtk_eint_set_type(struct irq_data *d,
return 0;
}
+static int mtk_eint_irq_set_wake(struct irq_data *d, unsigned int on)
+{
+ struct mtk_pinctrl *pctl = irq_data_get_irq_chip_data(d);
+ int shift = d-hwirq 0x1f;
+ int reg = d-hwirq 5;
+
+ if (on)
+ pctl-wake_mask[reg] |= BIT(shift);
+ else
+ pctl-wake_mask[reg] = ~BIT(shift);
+
+ return 0;
+}
Hi Maoguang,
You changed from set_bit/clear_bit to this, but didn't add any locking.
Since this is basic read/modify/write, is it OK to do it without
locking?
I believe calling .irq_set_wake() concurrently with itself is
protected by irq_get_desc_buslock():
int irq_set_irq_wake(unsigned int irq, unsigned int on)
{
unsigned long flags;
struct irq_desc *desc = irq_get_desc_buslock(irq, flags,
IRQ_GET_DESC_CHECK_GLOBAL);
int ret = 0;
...
ret = set_irq_wake_real(irq, on);
...
irq_put_desc_busunlock(desc, flags);
return ret;
}
I'm not 100% sure about the .suspend/.resume paths, but I don't think
they can occur during .irq_set_wake(), either.
Nor were they protected by the set_bit/clear_bit implementation.
-Dan
Joe.C
--
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/
--
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/3] sched: sync a se with its cfs_rq when attaching and dettaching
On Mon, Aug 17, 2015 at 04:45:49PM +0900, byungchul.p...@lge.com wrote: From: Byungchul Park byungchul.p...@lge.com i am very sorry for ugly versioning.. while i proposed several indivisual patches and was feedbacked, i felt that i needed to pack some patches into one series. thanks, byungchul change from v1 to v2 * introduce two functions for adjusting vruntime and load when attaching and detaching. * call the introduced functions instead of switched_from(to)_fair() directly in task_move_group_fair(). * add decaying logic for a se which has detached from a cfs_rq. Byungchul Park (3): sched: sync a se with its cfs_rq when attaching and dettaching sched: introduce functions for attaching(detaching) a task to cfs_rq sched: decay a detached se when it's attached to its cfs_rq kernel/sched/fair.c | 210 ++- 1 file changed, 109 insertions(+), 101 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- 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] mmc: dw_mmc: fix pio mode when internal dmac is enabled
[...]
- mmc-max_seg_size = mmc-max_req_size;
-#endif /* CONFIG_MMC_DW_IDMAC */
+ if (host-use_dma) {
+ mmc-max_segs = host-ring_size;
I expect this may cause a compiler error since host-ring_size is only
available in the struct dw_mci *host when CONFIG_MMC_DW_IDMAC is set.
I have already pulled in this patch from Jaehoon's pull request.
Perhaps I should only amend the patch and change the host-ring_size
to be always available no matter if CONFIG_MMC_DW_IDMAC is set or not?
Sorry for this. if you can, i think good that CONFIG_MMC_DW_IDMAC is removed
at struct dw_mci.
Could you amend it?
If you want to get patch, i will send patch at now.
No worries, I amend the patch myself.
Kind regards
Uffe
--
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: [RFCv5 PATCH 45/46] sched/cpufreq_sched: modify pcpu_capacity handling
Hi Peter,
On 16/08/15 21:35, Peter Zijlstra wrote:
On Tue, Jul 07, 2015 at 07:24:28PM +0100, Morten Rasmussen wrote:
From: Juri Lelli juri.le...@arm.com
Use the cpu argument of cpufreq_sched_set_cap() to handle per_cpu writes,
as the thing can be called remotely (e.g., from load balacing code).
cc: Ingo Molnar mi...@redhat.com
cc: Peter Zijlstra pet...@infradead.org
Signed-off-by: Juri Lelli juri.le...@arm.com
---
kernel/sched/cpufreq_sched.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/cpufreq_sched.c b/kernel/sched/cpufreq_sched.c
index 06ff183..b81ac779 100644
--- a/kernel/sched/cpufreq_sched.c
+++ b/kernel/sched/cpufreq_sched.c
@@ -151,7 +151,7 @@ void cpufreq_sched_set_cap(int cpu, unsigned long
capacity)
unsigned long capacity_max = 0;
/* update per-cpu capacity request */
-__this_cpu_write(pcpu_capacity, capacity);
+per_cpu(pcpu_capacity, cpu) = capacity;
policy = cpufreq_cpu_get(cpu);
if (IS_ERR_OR_NULL(policy)) {
Uhm,.. this function seems to hard assume its called for the local CPU.
It will only use the irq_queue_work_on() if the cpufreq thing requires
the thread, otherwise it will call the method directly on the calling
cpu.
True, but we still retrieve policy from cpu passed as argument; and
then we use policy to request a freq transition, that should end up
updating the right cpu.
Thanks,
- Juri
--
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 8/9] usb: serial: mxuport: Simplify return statement
On Tue, Aug 04, 2015 at 02:04:35PM +, Karajgaonkar, Saurabh (S.) wrote: From: Saurabh Karajgaonkar skara...@visteon.com Replace redundant variable use in return statement. Signed-off-by: Saurabh Karajgaonkar skara...@visteon.com --- drivers/usb/serial/mxuport.c | 10 +++--- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/usb/serial/mxuport.c b/drivers/usb/serial/mxuport.c index 460a406..31a8b47 100644 --- a/drivers/usb/serial/mxuport.c +++ b/drivers/usb/serial/mxuport.c @@ -1137,13 +1137,9 @@ static int mxuport_port_probe(struct usb_serial_port *port) return err; /* Set interface (RS-232) */ - err = mxuport_send_ctrl_urb(serial, RQ_VENDOR_SET_INTERFACE, - MX_INT_RS232, - port-port_number); - if (err) - return err; - - return 0; + return mxuport_send_ctrl_urb(serial, RQ_VENDOR_SET_INTERFACE, + MX_INT_RS232, + port-port_number); I do not consider this an improvement as it makes the final ctrl-request call look different from the previous two without any real benefit. I'll drop this one. Johan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/3] x86/entry/64: Refactor IRQ stacks and make them NMI-safe
On Sat, Jul 25, 2015 at 8:57 AM, Andy Lutomirski l...@kernel.org wrote: This will allow IRQ stacks to nest inside NMIs or similar entries that can happen during IRQ stack setup or teardown. The Xen code here has a confusing comment. The new macros won't work correctly if they're invoked with IRQs on. Add a check under CONFIG_DEBUG_ENTRY to detect that. +/* + * Enters the IRQ stack if we're not already using it. NMI-safe. Clobbers + * flags and puts old RSP into old_rsp, and leaves all other GPRs alone. + * Requires kernel GSBASE. + * + * The invariant is that, if irq_count != 1, then the IRQ stack is in use. + */ I might be wrong, but shouldn't be this read as 'if irq_count != -1' ? -- 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 V3 2/3] arm64: support initrd outside kernel linear map
Hi Mark,
On Sun, Aug 16, 2015 at 09:49:27PM +0100, Mark Salter wrote:
The use of mem= could leave part or all of the initrd outside of
the kernel linear map. This will lead to an error when unpacking
the initrd and a probable failure to boot. This patch catches that
situation and relocates the initrd to be fully within the linear
map.
Signed-off-by: Mark Salter msal...@redhat.com
---
arch/arm64/kernel/setup.c | 59
+++
1 file changed, 59 insertions(+)
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index f3067d4..5f45fd9 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -359,6 +359,64 @@ static void __init request_standard_resources(void)
}
}
+#ifdef CONFIG_BLK_DEV_INITRD
+/*
+ * Relocate initrd if it is not completely within the linear mapping.
+ * This would be the case if mem= cuts out all or part of it.
+ */
+static void __init relocate_initrd(void)
+{
+ phys_addr_t orig_start = __virt_to_phys(initrd_start);
+ phys_addr_t orig_end = __virt_to_phys(initrd_end);
Any particular reason to use the __* variants here?
+ phys_addr_t ram_end = memblock_end_of_DRAM();
+ phys_addr_t new_start;
+ unsigned long size, to_free = 0;
+ void *dest;
+
+ if (orig_end = ram_end)
+ return;
+
+ /* Note if any of original initrd will freeing below */
The comment doesn't make sense.
+ if (orig_start ram_end)
+ to_free = ram_end - orig_start;
+
+ size = orig_end - orig_start;
+
+ /* initrd needs to be relocated completely inside linear mapping */
+ new_start = memblock_find_in_range(0, PFN_PHYS(max_pfn),
+size, PAGE_SIZE);
+ if (!new_start)
+ panic(Cannot relocate initrd of size %ld\n, size);
+ memblock_reserve(new_start, size);
+
+ initrd_start = __phys_to_virt(new_start);
+ initrd_end = initrd_start + size;
+
+ pr_info(Moving initrd from [%llx-%llx] to [%llx-%llx]\n,
+ orig_start, orig_start + size - 1,
+ new_start, new_start + size - 1);
+
+ dest = (void *)initrd_start;
+
+ if (to_free) {
+ memcpy(dest, (void *)__phys_to_virt(orig_start), to_free);
+ dest += to_free;
+ }
+
+ copy_from_early_mem(dest, orig_start + to_free, size - to_free);
+
+ if (to_free) {
+ pr_info(Freeing original RAMDISK from [%llx-%llx]\n,
+ orig_start, orig_start + to_free - 1);
+ memblock_free(orig_start, to_free);
+ }
+}
+#else
+static inline void __init reserve_initrd(void)
relocate_initrd ?
Will
--
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] Update maintainers for DRM STI driver
On Thu, Aug 13, 2015 at 02:32:23PM +0200, Benjamin Gaignard wrote: Add Vincent Abriou and myself has maintainers. Signed-off-by: Benjamin Gaignard benjamin.gaign...@linaro.org --- MAINTAINERS | 9 + 1 file changed, 9 insertions(+) I'm glad to see this. I think we'll need a couple like this for other drivers, too. A couple that come to mind: atmel-hlcdc, msm (!), omapdrm, tilcdc and (possibly) vgem. Thierry signature.asc Description: PGP signature
Re: [PATCH] mmc: sdhci: also set driver type for MMC_DDR52
On Mon, 17 Aug 2015 19:34:39 +0800
Jisheng Zhang jszh...@marvell.com wrote:
commit 08f90f14aa93ad424c20bb176b52f329583e2183 (mmc: sdhci: clarify
DDR timing mode between SD-UHS and eMMC) added MMC_DDR52 as eMMC's DDR
mode to be distinguished from SD-UHS, but it missed setting driver type
for MMC_DDR52 timing mode. This patches adds the missing driver type
setting.
Sorry, please ignore this one. I made a mistake. will send out new version
Fixes: 79f7ae7c45a6(mmc: clarify DDR timing mode between SD-UHS and eMMC)
Signed-off-by: Jisheng Zhang jszh...@marvell.com
---
drivers/mmc/host/sdhci.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
index 1dbe932..32f2a07 100644
--- a/drivers/mmc/host/sdhci.c
+++ b/drivers/mmc/host/sdhci.c
@@ -1559,7 +1559,8 @@ static void sdhci_do_set_ios(struct sdhci_host *host,
struct mmc_ios *ios)
(ios-timing == MMC_TIMING_UHS_SDR25) ||
(ios-timing == MMC_TIMING_UHS_SDR50) ||
(ios-timing == MMC_TIMING_UHS_SDR104) ||
- (ios-timing == MMC_TIMING_UHS_DDR50))) {
+ (ios-timing == MMC_TIMING_UHS_DDR50) ||
+ (ios-timing == MMC_TIMING_MMC_DDR52))) {
u16 preset;
sdhci_enable_preset_value(host, true);
--
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 v4] fs/pstore: provide panic data even in suspend
From: Dongdong Yang yangdongd...@xiaomi.com
If system restart after panic, this patch also enables
panic and oops messages which in suspend context to be
logged into ramoops console buffer where it can be read
back at some later point.
Signed-off-by: Dongdong Yang yangdongd...@xiaomi.com
Signed-off-by: Linghua Gu guling...@xiaomi.com
Signed-off-by: Hui Du du...@xiaomi.com
---
fs/pstore/ram.c| 16
include/linux/printk.h | 6 ++
kernel/printk/printk.c | 6 ++
3 files changed, 28 insertions(+)
diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index 6c26c4d..3d981a1 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -642,8 +642,23 @@ static void ramoops_register_dummy(void)
}
}
+static int ramoops_console_notify(struct notifier_block *this,
+ unsigned long event, void *ptr)
+{
+ pr_emerg(ramoops unlock console ...\n);
+ emergency_unlock_console();
+
+ return 0;
+}
+
+static struct notifier_block ramoop_nb = {
+ .notifier_call = ramoops_console_notify,
+ .priority = INT_MAX,
+};
+
static int __init ramoops_init(void)
{
+ atomic_notifier_chain_register(panic_notifier_list, ramoop_nb);
ramoops_register_dummy();
return platform_driver_register(ramoops_driver);
}
@@ -654,6 +669,7 @@ static void __exit ramoops_exit(void)
platform_driver_unregister(ramoops_driver);
platform_device_unregister(dummy);
kfree(dummy_data);
+ atomic_notifier_chain_unregister(panic_notifier_list, ramoop_nb);
}
module_exit(ramoops_exit);
diff --git a/include/linux/printk.h b/include/linux/printk.h
index a6298b2..bd043ed 100644
--- a/include/linux/printk.h
+++ b/include/linux/printk.h
@@ -230,6 +230,12 @@ static inline void show_regs_print_info(const char
*log_lvl)
}
#endif
+/*
+ * Enables printk() before emergency_restart
+ * if we go into suspend states and run into oops.
+ */
+void emergency_unlock_console(void);
+
extern asmlinkage void dump_stack(void) __cold;
#ifndef pr_fmt
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index cf8c242..abb8af4 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2107,6 +2107,12 @@ void resume_console(void)
console_unlock();
}
+void emergency_unlock_console(void)
+{
+ if (oops_in_progress panic_timeout != 0 console_suspended)
+ resume_console();
+}
+
/**
* console_cpu_notify - print deferred console messages after CPU hotplug
* @self: notifier struct
--
2.5.0
v4:
- Move declaration emergency_unlock_console to printk.h from pstore_ram.h
- Update sign-off information.
Thanks,
Dongdong Yang
--
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 v4 2/5] PM / OPP: add a function to get the voltage for disabled OPPs
On Sat, Aug 15, 2015 at 06:59:25AM +0100, Viresh Kumar wrote:
On 14-08-15, 18:56, Javi Merino wrote:
The OPP library is now used for power models to calculate the power
that a device would consume at a specific OPP. To do that, we use a
simple power model which takes frequency and voltage as inputs. We get
the voltage and frequency from the OPP library.
The devfreq cooling device for the thermal framework controls temperature
by disabling OPPs. The power model needs to calculate the power that
would be consumed if we reenabled the OPP. dev_pm_opp_get_voltage()
doesn't work for disabled OPPs.
Add a dev_pm_opp_get_voltage_always() that works both for enabled and
disabled OPPs to be used by the power model. The documentation for this
function clearly states that you should use dev_pm_opp_get_voltage()
instead unless you know what you're doing.
Cc: Rafael J. Wysocki r...@rjwysocki.net
Cc: Viresh Kumar viresh.ku...@linaro.org
Signed-off-by: Javi Merino javi.mer...@arm.com
---
drivers/base/power/opp.c | 37 +
include/linux/pm_opp.h | 7 +++
2 files changed, 44 insertions(+)
diff --git a/drivers/base/power/opp.c b/drivers/base/power/opp.c
index 677fb2843553..b1a4216c7ec3 100644
--- a/drivers/base/power/opp.c
+++ b/drivers/base/power/opp.c
@@ -182,6 +182,43 @@ unsigned long dev_pm_opp_get_voltage(struct dev_pm_opp
*opp)
EXPORT_SYMBOL_GPL(dev_pm_opp_get_voltage);
/**
+ * dev_pm_opp_get_voltage_always() - Gets the voltage corresponding to an
opp
+ * @opp: opp for which voltage has to be returned for
+ *
+ * This function is similar to dev_pm_opp_get_voltage() except that it
+ * works for disabled opps as well. In most cases, you want to
+ * operate only on available opps so you should use
+ * dev_pm_opp_get_voltage() instead.
+ *
+ * Return: voltage in micro volt corresponding to the opp, else
+ * return 0
+ *
+ * Locking: This function must be called under rcu_read_lock(). opp is a
rcu
+ * protected pointer. This means that opp which could have been fetched by
+ * opp_find_freq_{exact,ceil,floor} functions is valid as long as we are
+ * under RCU lock. The pointer returned by the opp_find_freq family must be
+ * used in the same section as the usage of this function with the pointer
+ * prior to unlocking with rcu_read_unlock() to maintain the integrity of
the
+ * pointer.
+ */
+unsigned long dev_pm_opp_get_voltage_always(struct dev_pm_opp *opp)
+{
+ struct dev_pm_opp *tmp_opp;
+ unsigned long v = 0;
+
+ opp_rcu_lockdep_assert();
+
+ tmp_opp = rcu_dereference(opp);
+ if (unlikely(IS_ERR_OR_NULL(tmp_opp)))
+ pr_err(%s: Invalid parameters\n, __func__);
+ else
+ v = tmp_opp-u_volt;
+
+ return v;
+}
+EXPORT_SYMBOL_GPL(dev_pm_opp_get_voltage_always);
I will rather update dev_pm_opp_get_voltage() and remove the
'available' check. There is no need for that.
Even better, I'll do that for the next version.
Cheers,
Javi
--
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] gpiolib: irqchip: use different lockdep class for each gpio irqchip
On Fri, Aug 14, 2015 at 2:40 PM, Lars-Peter Clausen l...@metafoo.de wrote: On 08/14/2015 02:34 PM, Linus Walleij wrote: [...] Every chip will get their own lock class on the heap. But I think it is a bit kludgy. Is it not possible to have the lock key in struct gpio_chip be a real member instead of a pointer and get a per-chip lock that way? (...) struct lock_class_key lock_key; instead of: struct lock_class_key *lock_key; - problem solved, without kludgy header defines? Lock keys need to be in persistent memory since they have a unlimited life time. Once registered it is expected to exist until the system is reset. Aha I see. OK if we fix the documentation comment I guess we can go with this, even if it makes the header file somewhat hard to read. I have a bit of problem with it, because lockdep instrumentation is supposed to make development easier, not harder, now it helps in one end with lock validation and screws up in another end by creating API headers that are hopeless to read :( Linus -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] gpu/drm/i2c/adv7511: Fix license, set to GPL v2
On Tue, Aug 11, 2015 at 02:22:43PM +0200, Mike Looijmans wrote: Header claims GPL v2, so make the MODULE_LICENSE reflect that properly. Signed-off-by: Mike Looijmans mike.looijm...@topic.nl --- drivers/gpu/drm/i2c/adv7511.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) The subject prefix looks wrong. According to git log it should be drm: adv7511: instead. Otherwise: Reviewed-by: Thierry Reding tred...@nvidia.com signature.asc Description: PGP signature
Re: [RFC v2 0/1] i2c: acpi: scan ACPI enumerated I2C mux channels
On Fri, Aug 14, 2015 at 12:31:32PM -0700, Dustin Byford wrote:
(v2 corrects cc: list)
I would like to add support for scanning I2C devices connected to ACPI
OF compatible muxes described in ASL like this:
Device (MUX0)
{
Name (_ADR, 0x70)
Name (_HID, PRP0001)
Name (_CRS, ResourceTemplate()
{
I2cSerialBus (0x70, ControllerInitiated, I2C_SPEED,
AddressingMode7Bit, ^^SMB2, 0x00,
ResourceConsumer,,)
})
Name (_DSD, Package ()
{
ToUUID(daffd814-6eba-4d8c-8a91-bc9bbf4aa301),
Package () {
Package (2) { compatible, nxp,pca9548 },
}
Nice, you are using _DSD :-)
})
// MUX channels
Device (CH00) { Name (_ADR, 0x0) }
}
Scope(MUX0.CH00)
{
Device (TMP0) {
/* Temp sensor ASL, for example. */
}
}
It seems like a reasonable way to describe a common I2C component and
kernel support is almost there.
I had to:
1) Find and set an ACPI companion for the virtual I2C adapters created
for each mux channel.
2) Make sure to scan adap.dev when registering devices under each mux
channel.
At first, I was confused about why adap.dev-parent is used in
acpi_i2c_register_devices(). I found b34bb1ee from 4/2013 (ACPI / I2C:
Use parent's ACPI_HANDLE()), which offers an explanation.
This patch works well, but I'm not sure about the code to just fall back
to using adap.dev when adap.dev-parent doesn't have an ACPI companion.
Is there a more explicit check I can make to determine if the adapter
represents a mux channel?
I think the current code in I2C core is not actually doing the right
thing according the ACPI spec at least. To my understanding you can have
device with I2cSerialBus resource _anywhere_ in the namespace, not just
directly below the host controller. It's the ResourceSource attribute
that tells the corresponding host controller.
I wonder if it helps if we scan the whole namespace for devices with
I2cSerialBus that matches the just registered adapter? Something like
the patch below.
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index c83e4d13cfc5..2a309d27421a 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -94,27 +94,40 @@ struct gsb_buffer {
};
} __packed;
-static int acpi_i2c_add_resource(struct acpi_resource *ares, void *data)
+struct acpi_i2c_lookup {
+ struct i2c_board_info *info;
+ acpi_handle adapter_handle;
+ acpi_handle device_handle;
+};
+
+static int acpi_i2c_find_address(struct acpi_resource *ares, void *data)
{
- struct i2c_board_info *info = data;
+ struct acpi_i2c_lookup *lookup = data;
+ struct i2c_board_info *info = lookup-info;
+ struct acpi_resource_i2c_serialbus *sb;
+ acpi_handle adapter_handle;
+ acpi_status status;
- if (ares-type == ACPI_RESOURCE_TYPE_SERIAL_BUS) {
- struct acpi_resource_i2c_serialbus *sb;
+ if (info-addr || ares-type != ACPI_RESOURCE_TYPE_SERIAL_BUS)
+ return 1;
- sb = ares-data.i2c_serial_bus;
- if (!info-addr sb-type == ACPI_RESOURCE_SERIAL_TYPE_I2C) {
- info-addr = sb-slave_address;
- if (sb-access_mode == ACPI_I2C_10BIT_MODE)
- info-flags |= I2C_CLIENT_TEN;
- }
- } else if (!info-irq) {
- struct resource r;
+ sb = ares-data.i2c_serial_bus;
+ if (sb-type != ACPI_RESOURCE_SERIAL_TYPE_I2C)
+ return 1;
- if (acpi_dev_resource_interrupt(ares, 0, r))
- info-irq = r.start;
+ /*
+* Extract the ResourceSource and make sure that the handle matches
+* with the I2C adapter handle.
+*/
+ status = acpi_get_handle(lookup-device_handle,
+sb-resource_source.string_ptr,
+adapter_handle);
+ if (ACPI_SUCCESS(status) adapter_handle == lookup-adapter_handle) {
+ info-addr = sb-slave_address;
+ if (sb-access_mode == ACPI_I2C_10BIT_MODE)
+ info-flags |= I2C_CLIENT_TEN;
}
- /* Tell the ACPI core to skip this resource */
return 1;
}
@@ -123,6 +136,8 @@ static acpi_status acpi_i2c_add_device(acpi_handle handle,
u32 level,
{
struct i2c_adapter *adapter = data;
struct list_head resource_list;
+ struct acpi_i2c_lookup lookup;
+ struct resource_entry *entry;
struct i2c_board_info info;
struct acpi_device *adev;
int ret;
@@ -135,14 +150,37 @@ static acpi_status acpi_i2c_add_device(acpi_handle
handle, u32 level,
memset(info, 0, sizeof(info));
info.fwnode = acpi_fwnode_handle(adev);
+ memset(lookup, 0, sizeof(lookup));
+ lookup.adapter_handle = ACPI_HANDLE(adapter-dev.parent);
+
Re: [PATCH v7 5/5] iio: Documentation: Add IIO configfs documentation
Hi Daniel, Find minor comments. Regards, Vladimir On 11.08.2015 01:42, Daniel Baluta wrote: Signed-off-by: Daniel Baluta daniel.bal...@intel.com --- Documentation/ABI/testing/configfs-iio | 20 Documentation/iio/iio_configfs.txt | 57 ++ 2 files changed, 77 insertions(+) create mode 100644 Documentation/ABI/testing/configfs-iio create mode 100644 Documentation/iio/iio_configfs.txt diff --git a/Documentation/ABI/testing/configfs-iio b/Documentation/ABI/testing/configfs-iio new file mode 100644 index 000..1fd7cf4 --- /dev/null +++ b/Documentation/ABI/testing/configfs-iio @@ -0,0 +1,20 @@ +What: /config/iio +Date: May 2015 +KernelVersion: 4.2 +Contact: linux-...@vger.kernel.org +Description: + This represents Industrial IO configuration entry point + directory. It contains sub-groups corresponding to IIO + objects. + +What: /config/iio/triggers +Date: August 2015 +KernelVersion: 4.2 +Description: + Industrial IO software triggers directory. + +What: /config/iio/triggers/hrtimer +Date: August 2015 +KernelVersion: 4.2 +Description: + Industrial IO hrtimer based software triggers directory. diff --git a/Documentation/iio/iio_configfs.txt b/Documentation/iio/iio_configfs.txt new file mode 100644 index 000..7c56997 --- /dev/null +++ b/Documentation/iio/iio_configfs.txt @@ -0,0 +1,57 @@ +Industrial IIO configfs support + +1. Overview + +Configfs is a filesystem-based manager of kernel objects. IIO uses some +objects that could be easily configured using configfs (e.g.: devices, +triggers). + +See Documentation/filesystems/configfs/configfs.txt for more information +about how configfs works. + +2. Usage + +In order to use configfs support in IIO we need to select it at compile +time via CONFIG_IIO_CONFIGFS config option. + +Then, mount the configfs filesystem (usually under /config directory): + +$ mkdir /config +$ mount -t configfs none /config + +At this point, all default IIO groups will be created and can be accessed +under /config/iio. Next chapters will describe available IIO configuration +objects. + +3. Software triggers + +One of the IIO default configfs groups is the triggers groups. It is +automagically accessible when the configfs is mounted and can be found +under /config/iio/triggers. + +Software triggers are created under /config/iio/triggers directory. There +must exist an associated kernel module that implements a software trigger type. + +We support now the following software trigger types: + * hrtimer, uses high resolution timers as interrupt source implemened + by the iio-trig-hrtimer.c module. + +3.1 Software triggers creation and destruction + +As simply as: + +$ insmod iio-trig-hrtimer.ko +$ ls /config/triggers ls /config/iio/triggers/ +hrtimer +$ mkdir /config/triggers/hrtimer/trig1 mkdir /config/iio/triggers/hrtimer/trig1 This is confusing: $ cat /sys/bus//iio/devices/trigger0/name trig1 How may I know that this is a hrtimer trigger in case I've enabled couple of triggers or when sw_trigger support extends with other then hrtimer trigger? + +$ rmdir /config/triggers/hrtimer/trig1 ditto +$ rmmod iio-trig-hrtimer + +Each trigger can have one or more attributes specific to the trigger type. + +3.2 hrtimer trigger types attributes + +hrtimer trigger type doesn't have any configurable attribute from /config dir, +but hrtimer triggers have the sampling_frequency attribute under /sys/bus/iio/devices/triggerX +directory. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 3/8] add fpga manager core
On Thu 2015-08-13 12:37:27, at...@opensource.altera.com wrote: From: Alan Tull at...@opensource.altera.com API to support programming FPGA. I'd do s/fpga/FPGA/ in the comments, too. Otherwise looks ok to me. Acked-by: Pavel Machek pa...@denx.de -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: fs: out of bounds on stack in iov_iter_advance
On 08/15/2015 11:13 PM, Chuck Ebbert wrote:
On Wed, 12 Aug 2015 10:13:24 -0400
Sasha Levin sasha.le...@oracle.com wrote:
While fuzzing with trinity inside a KVM tools guest running -next I've
stumbled on the following:
[64092.216447]
==
[64092.217840] BUG: KASan: out of bounds on stack in
iov_iter_advance+0x3b7/0x480 at addr 88040506fd48
[64092.219314] Read of size 8 by task trinity-c194/11387
[64092.220114] page:ea0010141bc0 count:0 mapcount:0 mapping:
(null) index:0x2
[64092.221354] flags: 0x46f8000()
[64092.221998] page dumped because: kasan: bad access detected
[64092.222879] CPU: 4 PID: 11387 Comm: trinity-c194 Not tainted
4.2.0-rc6-next-20150810-sasha-00040-g12ad0db3-dirty #2427
[64092.224537] 88040506fd30 88040506fa88 9ce7763b
88040506fb10
[64092.225763] 88040506fb00 9376b1be
880270108600
[64092.226992] 0282
[64092.228221] Call Trace:
[64092.228679] dump_stack (lib/dump_stack.c:52)
[64092.231252] kasan_report_error (mm/kasan/report.c:132
mm/kasan/report.c:193)
[64092.232219] __asan_report_load8_noabort (mm/kasan/report.c:251)
[64092.234167] iov_iter_advance (lib/iov_iter.c:511)
[64092.235105] generic_file_read_iter (mm/filemap.c:1743)
[64092.241532] blkdev_read_iter (fs/block_dev.c:1649)
[64092.242448] __vfs_read (fs/read_write.c:423 fs/read_write.c:434)
[64092.246949] vfs_read (fs/read_write.c:454)
[64092.247743] SyS_pread64 (fs/read_write.c:607 fs/read_write.c:594)
[64092.250445] entry_SYSCALL_64_fastpath (arch/x86/entry/entry_64.S:186)
[64092.251440] Memory state around the buggy address:
[64092.252221] 88040506fc00: 00 00 00 f1 f1 f1 f1 00 00 00 00 00 f4 f4
f4 f3
[64092.253340] 88040506fc80: f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00
00 00
[64092.254456] 88040506fd00: 00 00 f1 f1 f1 f1 00 00 f4 f4 f2 f2 f2 f2
00 00
[64092.255566] ^
[64092.256432] 88040506fd80: 00 00 00 f4 f4 f4 f2 f2 f2 f2 00 00 00 00
00 f4
[64092.257557] 88040506fe00: f4 f4 f3 f3 f3 f3 00 00 00 00 00 00 00 00
00 00
[64092.258684]
==
I tried to debug this but kasan doesn't print much useful information
for stack out of bounds access. It shows the address that's being
accessed but it doesn't show the value of the boundary that was
exceeded.
This could be estimated by looking at the shadow memory:
88040506fd00: 00 00 f1 f1 f1 f1 00 00 f4 [f4] f2 f2 f2 f2 00 00
Each byte in shadow represents 8 bytes of memory. So f1 - is the left redzone
of the stack frame.
2 zeroes is probably 'struct iovec iov' defined in new_sync_read(). The next
two f4 is redzone.
We hit the second f4, which means that we accessed iov[1].iov_len
This bug is similar to recently found bug in 9p:
http://thread.gmane.org/gmane.linux.kernel/1931799/focus=1936542
Such report could be produced if retval count.
generic_file_read_iter():
...
size_t count = iov_iter_count(iter);
...
if (!count)
goto out; /* skip atime */
size = i_size_read(inode);
retval = filemap_write_and_wait_range(mapping, pos,
pos + count - 1);
if (!retval) {
struct iov_iter data = *iter;
retval = mapping-a_ops-direct_IO(iocb, data, pos);
}
if (retval 0) {
*ppos = pos + retval;
iov_iter_advance(iter, retval);
So either filemap_write_and_wait_range() or mapping-a_ops-direct_IO()
returned more
than 'count'.
And the stack dump doesn't show any addresses either - just
contents. It would be nice to see a full stack frame dump showing
where all the parent frames are too.
Yes, I think it might be helpful to dump some portion of stack around the
access address.
Also too the file and line number
(lib/iov_iter.c:511) are completely useless because of inlining,
though that's not kasan's fault.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 1/5] drm/edid: Add support to get edid early
On 17/08/15 08:52, Jani Nikula wrote:
On Fri, 14 Aug 2015, Srinivas Kandagatla srinivas.kandaga...@linaro.org wrote:
This patch adds support to get edid way early before the connector is
created, this is mainly used for panel drivers to auto-probe the panel
based on the vendor and product id from EDID.
Signed-off-by: Srinivas Kandagatla srinivas.kandaga...@linaro.org
---
drivers/gpu/drm/drm_edid.c | 8
include/drm/drm_crtc.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 7087da3..30359cd 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1388,6 +1388,14 @@ struct edid *drm_get_edid(struct drm_connector
*connector,
}
EXPORT_SYMBOL(drm_get_edid);
+struct edid *drm_get_edid_early(struct i2c_adapter *adapter)
+{
+ struct drm_connector dummy_connector;
+
+ return drm_get_edid(dummy_connector, adapter);
This will oops the kernel on bad EDID.
Thanks for quick review,
Yes, you are right it would blow up on dev_warn(connector-dev-dev, ...
May we can fix this if we are happy to take this approach of getting
edid early.
--srini
BR,
Jani.
+}
+EXPORT_SYMBOL(drm_get_edid_early);
+
/**
* drm_edid_duplicate - duplicate an EDID and the extensions
* @edid: EDID to duplicate
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 57ca8cc..35d8763 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -1330,6 +1330,7 @@ extern void drm_reinit_primary_mode_group(struct
drm_device *dev);
extern bool drm_probe_ddc(struct i2c_adapter *adapter);
extern struct edid *drm_get_edid(struct drm_connector *connector,
struct i2c_adapter *adapter);
+extern struct edid *drm_get_edid_early(struct i2c_adapter *adapter);
extern struct edid *drm_edid_duplicate(const struct edid *edid);
extern int drm_add_edid_modes(struct drm_connector *connector, struct edid
*edid);
extern void drm_mode_config_init(struct drm_device *dev);
--
1.9.1
___
dri-devel mailing list
dri-de...@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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 6/8] iio: gyro: bmg160: optimize i2c transfers in trigger handler
-Original Message-
From: Markus Pargmann [mailto:m...@pengutronix.de]
Sent: 17 August, 2015 12:10
To: Jonathan Cameron
Cc: Tirdea, Irina; Wolfram Sang; linux-...@vger.kernel.org;
linux-...@vger.kernel.org; linux-kernel@vger.kernel.org; Pandruvada,
Srinivas; Peter Meerwald
Subject: Re: [PATCH v5 6/8] iio: gyro: bmg160: optimize i2c transfers in
trigger handler
On Sun, Aug 16, 2015 at 10:24:47AM +0100, Jonathan Cameron wrote:
On 12/08/15 15:31, Irina Tirdea wrote:
Some i2c busses (e.g.: Synopsys DesignWare I2C adapter) need to
enable/disable the bus at each i2c transfer and must wait for
the enable/disable to happen before sending the data.
When reading data in the trigger handler, the bmg160 driver does
one i2c transfer for each axis. This has an impact on the frequency
of the gyroscope at high sample rates due to additional delays
introduced by the i2c bus at each transfer.
Reading all axis values in one i2c transfer reduces the delays
introduced by the i2c bus. Uses i2c_smbus_read_i2c_block_data_or_emulated
that will fallback to reading each axis as a separate word in case i2c
block read is not supported.
Signed-off-by: Irina Tirdea irina.tir...@intel.com
Acked-by: Jonathan Cameron ji...@kernel.org
Acked-by: Srinivas Pandruvada srinivas.pandruv...@linux.intel.com
Note, that in the meantime the bmg160 driver just went all regmap
on us (as part of adding SPI support - though that step hasn't
happened yet). Hence we'll need a means of telling regmap about this
possibility.
Perhaps this is covered by a regmap_bulk_read()?
I think it is. However, if that does not work for the i2c controllers I'm
testing with I'll take a look at the patches you mention below.
I'll rebase this patch on top of your next version for bmg160 and
resend.
Thanks,
Irina
The series[1] I am working on implements a i2c smbus block data regmap
bus driver. Regmap should then automatically do a block read in
regmap_bulk_read.
Patch 15 introduces the i2c block data regmap bus driver[2].
I am only implementing this so I don't break bmc150 behavior. I do not
have the hardware available to test this regmap driver so it would be great
if someone else could test one of the next versions of this bus driver.
Best regards,
Markus
[1] http://thread.gmane.org/gmane.linux.kernel/2018643
[2] http://thread.gmane.org/gmane.linux.kernel/2018639
---
drivers/iio/gyro/bmg160.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/iio/gyro/bmg160.c b/drivers/iio/gyro/bmg160.c
index b2a6ccb..1ff306d 100644
--- a/drivers/iio/gyro/bmg160.c
+++ b/drivers/iio/gyro/bmg160.c
@@ -772,6 +772,7 @@ static const struct iio_event_spec bmg160_event = {
.sign = 's',\
.realbits = 16, \
.storagebits = 16, \
+ .endianness = IIO_LE, \
}, \
.event_spec = bmg160_event,\
.num_event_specs = 1\
@@ -809,19 +810,16 @@ static irqreturn_t bmg160_trigger_handler(int irq,
void *p)
struct iio_poll_func *pf = p;
struct iio_dev *indio_dev = pf-indio_dev;
struct bmg160_data *data = iio_priv(indio_dev);
- int bit, ret, i = 0;
+ int ret = 0;
mutex_lock(data-mutex);
- for (bit = 0; bit AXIS_MAX; bit++) {
- ret = i2c_smbus_read_word_data(data-client,
-BMG160_AXIS_TO_REG(bit));
- if (ret 0) {
- mutex_unlock(data-mutex);
- goto err;
- }
- data-buffer[i++] = ret;
- }
+ ret = i2c_smbus_read_i2c_block_data_or_emulated(data-client,
+ BMG160_REG_XOUT_L,
+ AXIS_MAX * 2,
+ (u8 *)data-buffer);
mutex_unlock(data-mutex);
+ if (ret 0)
+ goto err;
iio_push_to_buffers_with_timestamp(indio_dev, data-buffer,
pf-timestamp);
--
To unsubscribe from this list: send the line unsubscribe linux-iio in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
Re: [PATCH RFC] eeprom: at24: extend driver to plug into the NVMEM framework
Hi Andrew,
Thanks for the patch, few comments other than Stefan's comments.
On 16/08/15 03:54, Andrew Lunn wrote:
Add a read only regmap for accessing the EEPROM, and then use that
with the NVMEM framework.
Signed-off-by: Andrew Lunn and...@lunn.ch
---
drivers/misc/eeprom/at24.c | 65 ++
1 file changed, 65 insertions(+)
diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index 2d3db81be099..0e80c0c09d4e 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -22,6 +22,8 @@
#include linux/jiffies.h
#include linux/of.h
#include linux/i2c.h
+#include linux/nvmem-provider.h
+#include linux/regmap.h
#include linux/platform_data/at24.h
/*
@@ -69,6 +71,10 @@ struct at24_data {
unsigned write_max;
unsigned num_addresses;
+ struct regmap_config regmap_config;
+ struct nvmem_config nvmem_config;
+ struct nvmem_device *nvmem;
+
/*
* Some chips tie up multiple I2C addresses; dummy devices reserve
* them for us, and we'll use them with SMBus calls.
@@ -471,6 +477,34 @@ static ssize_t at24_macc_write(struct memory_accessor
*macc, const char *buf,
/*-*/
+/*
+ * Provide a regmap interface, which is registered with the NVMEM
+ * framework
+*/
+static int at24_regmap_read(void *context, const void *reg, size_t reg_size,
+ void *val, size_t val_size)
+{
+ struct at24_data *at24 = context;
+ off_t offset = *(u32 *)reg;
+
+ return at24_read(at24, val, offset, val_size);
+}
+
+static int at24_regmap_write(void *context, const void *data, size_t count)
+{
+ struct at24_data *at24 = context;
+
+ return at24_write(at24, data, 0, count);
+}
+
+static const struct regmap_bus at24_regmap_bus = {
+ .read = at24_regmap_read,
+ .write = at24_regmap_write,
+ .reg_format_endian_default = REGMAP_ENDIAN_NATIVE,
+};
+
+/*-*/
+
#ifdef CONFIG_OF
static void at24_get_ofdata(struct i2c_client *client,
struct at24_platform_data *chip)
@@ -502,6 +536,7 @@ static int at24_probe(struct i2c_client *client, const
struct i2c_device_id *id)
int err;
unsigned i, num_addresses;
kernel_ulong_t magic;
+ struct regmap *regmap;
if (client-dev.platform_data) {
chip = *(struct at24_platform_data *)client-dev.platform_data;
@@ -644,6 +679,30 @@ static int at24_probe(struct i2c_client *client, const
struct i2c_device_id *id)
if (err)
goto err_clients;
+ at24-regmap_config.reg_bits = 32;
+ at24-regmap_config.val_bits = 8;
+ at24-regmap_config.reg_stride = 1;
+ at24-regmap_config.max_register = at24-bin.size - 1;
+
+ regmap = devm_regmap_init(client-dev, at24_regmap_bus, at24,
+ at24-regmap_config);
+ if (IS_ERR(regmap)) {
+ dev_err(client-dev, regmap init failed\n);
+ err = PTR_ERR(regmap);
+ goto err_sysfs;
+ }
+
+ at24-nvmem_config.name = dev_name(client-dev);
+ at24-nvmem_config.dev = client-dev;
+ at24-nvmem_config.read_only = !writable;
+ at24-nvmem_config.owner = THIS_MODULE;
+
+ at24-nvmem = nvmem_register(at24-nvmem_config);
+ if (IS_ERR(at24-nvmem)) {
+ err = PTR_ERR(at24-nvmem);
+ goto err_sysfs;
+ }
+
i2c_set_clientdata(client, at24);
dev_info(client-dev, %zu byte %s EEPROM, %s, %u bytes/write\n,
@@ -662,6 +721,9 @@ static int at24_probe(struct i2c_client *client, const
struct i2c_device_id *id)
return 0;
+err_sysfs:
+ sysfs_remove_bin_file(client-dev.kobj, at24-bin);
+
?? Not sure Why this code is still needed. Can't we remove it?
Is this the the same binary file which is exposed by nvmem in
/sys/bus/nvmem too?
--srini
err_clients:
for (i = 1; i num_addresses; i++)
if (at24-client[i])
@@ -676,6 +738,9 @@ static int at24_remove(struct i2c_client *client)
int i;
at24 = i2c_get_clientdata(client);
+
+ nvmem_unregister(at24-nvmem);
+
sysfs_remove_bin_file(client-dev.kobj, at24-bin);
for (i = 1; i at24-num_addresses; i++)
--
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, apei, arm64: APEI initial support for aarch64.
On Fri, Aug 14, 2015 at 01:35:53PM +0100, fu@linaro.org wrote:
From: Tomasz Nowicki tomasz.nowi...@linaro.org
This commit provides APEI arch-specific bits for aarch64
Changelog:
Fu Wei:
Move arch_apei_flush_tlb_one() to arch/arm64/include/asm/apci.h.
Delete arch/arm64/kernel/apei.c.
Add #ifdef CONFIG_ACPI_APEI for acpi_disable_cmcff.
Signed-off-by: Tomasz Nowicki tomasz.nowi...@linaro.org
Signed-off-by: Fu Wei fu@linaro.org
---
arch/arm64/Kconfig| 1 +
arch/arm64/include/asm/acpi.h | 11 +++
arch/arm64/kernel/acpi.c | 4
3 files changed, 16 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 318175f..6144c9d 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -3,6 +3,7 @@ config ARM64
select ACPI_CCA_REQUIRED if ACPI
select ACPI_GENERIC_GSI if ACPI
select ACPI_REDUCED_HARDWARE_ONLY if ACPI
+ select HAVE_ACPI_APEI if ACPI
select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_GCOV_PROFILE_ALL
diff --git a/arch/arm64/include/asm/acpi.h b/arch/arm64/include/asm/acpi.h
index a17b623..ced6e25 100644
--- a/arch/arm64/include/asm/acpi.h
+++ b/arch/arm64/include/asm/acpi.h
@@ -22,6 +22,7 @@
#ifdef CONFIG_ACPI_APEI
#include linux/efi.h
#include asm/pgtable.h
+#include asm/tlbflush.h
#endif
/* Macros for consistency checks of the GICC subtable of MADT */
@@ -52,6 +53,9 @@ typedef u64 phys_cpuid_t;
extern int acpi_disabled;
extern int acpi_noirq;
extern int acpi_pci_disabled;
+#ifdef CONFIG_ACPI_APEI
+extern int acpi_disable_cmcff;
+#endif
static inline void disable_acpi(void)
{
@@ -89,6 +93,13 @@ static inline bool acpi_has_cpu_in_madt(void)
static inline void arch_fix_phys_package_id(int num, u32 slot) { }
void __init acpi_init_cpus(void);
+#ifdef CONFIG_ACPI_APEI
+static inline void arch_apei_flush_tlb_one(unsigned long addr)
+{
+ flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
+}
+#endif
Looking at the callers of this function, I suspect we could downgrade it
to a local CPU invalidation if we wanted. However, this isn't a hot-path
so it's fine to stay like it is for now.
Will
--
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/
Make RCU tree CPU topology aware?
Hi Paul, Currently RCU tree distributes CPUs to leafs based on consequent CPU IDs. That means CPUs from remote caches and even nodes might end up in the same leaf. I did not research the impact, but at the glance that seems at least sub-optimal; especially in case of remote nodes, when CPUs access each others' memory? I am thinking of topology-aware RCU geometry where the RCU tree reflects the actual system topology. I.e by borrowing it from schedulling domains or soemthing like that. Do you think it worth the effort to research this question or I am missing something and the current access patterns are just optimal? Thanks! -- Regards, Alexander Gordeev agord...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drm: panel: simple: add QiaoDian qd43003c0-40
On 17/08/2015 at 12:09:14 +0200, Thierry Reding wrote : On Sat, Aug 01, 2015 at 12:44:31AM +0200, Alexandre Belloni wrote: From: Josh Wu josh...@atmel.com The QiaoDian Xianshi QD43003C0-40 is a 43 TFT LCD panel. Timings from the OTA5180A document, ver 0.9, section 10.1.1: http://www.orientdisplay.com/pdf/OTA5180A.pdf Signed-off-by: Josh Wu josh...@atmel.com Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com --- .../devicetree/bindings/panel/qd,qd43003c0-40.txt | 7 ++ drivers/gpu/drm/panel/panel-simple.c | 26 ++ 2 files changed, 33 insertions(+) create mode 100644 Documentation/devicetree/bindings/panel/qd,qd43003c0-40.txt You didn't run this through scripts/get_maintainer.pl, did you? It would also help to use the standard prefix (drm/panel: ) because I end up filtering for that occasionally in case somebody didn't Cc me on panel patches. I'm pretty sure I did as you were the only one in the To: field. Maybe you want to check your spam filter. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] powerpc32: optimise csum_partial() loop
Le 07/08/2015 01:25, Segher Boessenkool a écrit : On Thu, Aug 06, 2015 at 05:45:45PM -0500, Scott Wood wrote: If this makes performance non-negligibly worse on other 32-bit chips, and is an important improvement on 8xx, then we can use an ifdef since 8xx already requires its own kernel build. I'd prefer to see a benchmark showing that it actually does make things worse on those chips, though. And I'd like to see a benchmark that shows it *does not* hurt performance on most chips, and does improve things on 8xx, and by how much. But it isn't *me* who has to show that, it is not my patch. Ok, following this discussion I made some additional measurement and it looks like: * There is almost no change on the 885 * There is a non negligeable degradation on the 8323 (19.5 tb ticks instead of 15.3) Thanks for pointing this out, I think my patch is therefore not good. Christophe -- 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] lpfc: Fix possible use-after-free and double free in lpfc_mbx_cmpl_rdp_page_a2()
If the bf_get() call in lpfc_mbx_cmpl_rdp_page_a2() does succeeds, execution continues normally and mp gets kfree()d. If the subsequent call to lpfc_sli_issue_mbox() fails execution jumps to the error label where lpfc_mbuf_free() is called with mp-virt and mp-phys as function arguments. This is the use after free. Following the use after free mp gets kfree()d again which is a double free. Signed-off-by: Johannes Thumshirn jthumsh...@suse.de --- drivers/scsi/lpfc/lpfc_mbox.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/scsi/lpfc/lpfc_mbox.c b/drivers/scsi/lpfc/lpfc_mbox.c index eb62772..4abb93a 100644 --- a/drivers/scsi/lpfc/lpfc_mbox.c +++ b/drivers/scsi/lpfc/lpfc_mbox.c @@ -2284,7 +2284,7 @@ lpfc_mbx_cmpl_rdp_page_a2(struct lpfc_hba *phba, LPFC_MBOXQ_t *mbox) (struct lpfc_rdp_context *)(mbox-context2); if (bf_get(lpfc_mqe_status, mbox-u.mqe)) - goto error; + goto error_mbuf_free; lpfc_sli_bemem_bcopy(mp-virt, rdp_context-page_a2, DMP_SFF_PAGE_A2_SIZE); @@ -2299,13 +2299,14 @@ lpfc_mbx_cmpl_rdp_page_a2(struct lpfc_hba *phba, LPFC_MBOXQ_t *mbox) mbox-mbox_cmpl = lpfc_mbx_cmpl_rdp_link_stat; mbox-context2 = (struct lpfc_rdp_context *) rdp_context; if (lpfc_sli_issue_mbox(phba, mbox, MBX_NOWAIT) == MBX_NOT_FINISHED) - goto error; + goto error_cmd_free; return; -error: +error_mbuf_free: lpfc_mbuf_free(phba, mp-virt, mp-phys); kfree(mp); +error_cmd_free: lpfc_sli4_mbox_cmd_free(phba, mbox); rdp_context-cmpl(phba, rdp_context, FAILURE); } -- 2.5.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] [media] DocBook media: Fix typo the the in xml files
This patch fix spelling typo the the found in controls.xml and vidioc-g-param.xml. These xml files are generated from NOT any files, so I have to fix these xml files. Signed-off-by: Masanari Iida standby2...@gmail.com --- Documentation/DocBook/media/v4l/controls.xml | 2 +- Documentation/DocBook/media/v4l/vidioc-g-parm.xml | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/DocBook/media/v4l/controls.xml b/Documentation/DocBook/media/v4l/controls.xml index 6e1667b..33aece5 100644 --- a/Documentation/DocBook/media/v4l/controls.xml +++ b/Documentation/DocBook/media/v4l/controls.xml @@ -3414,7 +3414,7 @@ giving priority to the center of the metered area./entry row entryconstantV4L2_EXPOSURE_METERING_MATRIX/constantnbsp;/entry entryA multi-zone metering. The light intensity is measured -in several points of the frame and the the results are combined. The +in several points of the frame and the results are combined. The algorithm of the zones selection and their significance in calculating the final value is device dependent./entry /row diff --git a/Documentation/DocBook/media/v4l/vidioc-g-parm.xml b/Documentation/DocBook/media/v4l/vidioc-g-parm.xml index f4e28e7..7217287 100644 --- a/Documentation/DocBook/media/v4l/vidioc-g-parm.xml +++ b/Documentation/DocBook/media/v4l/vidioc-g-parm.xml @@ -267,7 +267,7 @@ is intended for still imaging applications. The idea is to get the best possible image quality that the hardware can deliver. It is not defined how the driver writer may achieve that; it will depend on the hardware and the ingenuity of the driver writer. High quality mode is -a different mode from the the regular motion video capture modes. In +a different mode from the regular motion video capture modes. In high quality mode:itemizedlist listitem paraThe driver may be able to capture higher -- 2.5.0.234.gefc8a62 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v10 8/8] staging: add simple-fpga-bus
On Thu 2015-08-13 12:37:32, at...@opensource.altera.com wrote: From: Alan Tull at...@opensource.altera.com Add simple fpga bus. This is a bus that configures an fpga and its bridges before populating the devices below it. This is intended for use with device tree overlays. Note that FPGA bridges are seen as reset controllers so no special framework for FPGA bridges will need to be added. This supports fpga use where hardware blocks on a fpga will need drivers (as opposed to fpga used as an acceleration without drivers.) Signed-off-by: Alan Tull at...@opensource.altera.com 7,8: Acked-by: Pavel Machek pa...@denx.de -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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/
[PATCH v4 3/5] pci: altera: Add Altera PCIe MSI driver
This patch adds Altera PCIe MSI driver. This soft IP supports configurable
number of vectors, which is a dts parameter.
Signed-off-by: Ley Foon Tan lf...@altera.com
---
drivers/pci/host/Kconfig | 8 +
drivers/pci/host/Makefile | 1 +
drivers/pci/host/pcie-altera-msi.c | 322 +
3 files changed, 331 insertions(+)
create mode 100644 drivers/pci/host/pcie-altera-msi.c
diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
index 4b4754a..d28cc6d 100644
--- a/drivers/pci/host/Kconfig
+++ b/drivers/pci/host/Kconfig
@@ -152,4 +152,12 @@ config PCIE_ALTERA
Say Y here if you want to enable PCIe controller support for Altera
SoCFPGA family of SoCs.
+config PCIE_ALTERA_MSI
+ bool Altera PCIe MSI feature
+ depends on PCI_MSI
+ select PCI_MSI_IRQ_DOMAIN
+ help
+ Say Y here if you want PCIe MSI support for the Altera SocFPGA SoC.
+ This MSI driver supports Altera MSI to GIC controller IP.
+
endmenu
diff --git a/drivers/pci/host/Makefile b/drivers/pci/host/Makefile
index 6954f76..6c4913d 100644
--- a/drivers/pci/host/Makefile
+++ b/drivers/pci/host/Makefile
@@ -18,3 +18,4 @@ obj-$(CONFIG_PCIE_IPROC) += pcie-iproc.o
obj-$(CONFIG_PCIE_IPROC_PLATFORM) += pcie-iproc-platform.o
obj-$(CONFIG_PCIE_IPROC_BCMA) += pcie-iproc-bcma.o
obj-$(CONFIG_PCIE_ALTERA) += pcie-altera.o
+obj-$(CONFIG_PCIE_ALTERA_MSI) += pcie-altera-msi.o
diff --git a/drivers/pci/host/pcie-altera-msi.c
b/drivers/pci/host/pcie-altera-msi.c
new file mode 100644
index 000..d3ad96f
--- /dev/null
+++ b/drivers/pci/host/pcie-altera-msi.c
@@ -0,0 +1,322 @@
+/*
+ * Copyright Altera Corporation (C) 2013-2015. All rights reserved
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+#include linux/interrupt.h
+#include linux/irqchip/chained_irq.h
+#include linux/module.h
+#include linux/msi.h
+#include linux/of_address.h
+#include linux/of_irq.h
+#include linux/of_pci.h
+#include linux/pci.h
+#include linux/platform_device.h
+#include linux/slab.h
+
+#define MSI_STATUS 0x0
+#define MSI_ERROR 0x4
+#define MSI_INTMASK0x8
+
+#define MAX_MSI_VECTORS32
+struct altera_msi {
+ DECLARE_BITMAP(used, MAX_MSI_VECTORS);
+ struct mutexlock; /* proctect used variable */
+ struct platform_device *pdev;
+ struct irq_domain *msi_domain;
+ struct irq_domain *inner_domain;
+ void __iomem*csr_base;
+ void __iomem*vector_base;
+ phys_addr_t vector_phy;
+ u32 num_of_vectors;
+ int irq;
+};
+
+static inline void msi_writel(struct altera_msi *msi, u32 value, u32 reg)
+{
+ writel_relaxed(value, msi-csr_base + reg);
+}
+
+static inline u32 msi_readl(struct altera_msi *msi, u32 reg)
+{
+ return readl_relaxed(msi-csr_base + reg);
+}
+
+static void altera_msi_isr(unsigned int irq, struct irq_desc *desc)
+{
+ struct irq_chip *chip = irq_desc_get_chip(desc);
+ struct altera_msi *msi;
+ unsigned long status;
+ u32 num_of_vectors;
+ u32 bit;
+ u32 virq;
+
+ chained_irq_enter(chip, desc);
+ msi = irq_desc_get_handler_data(desc);
+ num_of_vectors = msi-num_of_vectors;
+
+ do {
+ status = msi_readl(msi, MSI_STATUS);
+ if (!status)
+ break;
+
+ do {
+ bit = find_first_bit(status, num_of_vectors);
+ /* Dummy read from vector to clear the interrupt */
+ readl_relaxed(msi-vector_base + (bit * sizeof(u32)));
+
+ virq = irq_find_mapping(msi-inner_domain, bit);
+ if (virq test_bit(bit, msi-used))
+ generic_handle_irq(virq);
+ else
+ dev_err(msi-pdev-dev, unexpected MSI\n);
+
+ /* Clear the bit from status and repeat without reading
+* again status register. */
+ __clear_bit(bit, status);
+ } while (status);
+ } while (1);
+
+ chained_irq_exit(chip, desc);
+}
+
+static struct irq_chip altera_msi_irq_chip = {
+ .name = Altera PCIe MSI,
+ .irq_enable = pci_msi_unmask_irq,
Re: [PATCH v5 6/8] iio: gyro: bmg160: optimize i2c transfers in trigger handler
On Sun, Aug 16, 2015 at 10:24:47AM +0100, Jonathan Cameron wrote:
On 12/08/15 15:31, Irina Tirdea wrote:
Some i2c busses (e.g.: Synopsys DesignWare I2C adapter) need to
enable/disable the bus at each i2c transfer and must wait for
the enable/disable to happen before sending the data.
When reading data in the trigger handler, the bmg160 driver does
one i2c transfer for each axis. This has an impact on the frequency
of the gyroscope at high sample rates due to additional delays
introduced by the i2c bus at each transfer.
Reading all axis values in one i2c transfer reduces the delays
introduced by the i2c bus. Uses i2c_smbus_read_i2c_block_data_or_emulated
that will fallback to reading each axis as a separate word in case i2c
block read is not supported.
Signed-off-by: Irina Tirdea irina.tir...@intel.com
Acked-by: Jonathan Cameron ji...@kernel.org
Acked-by: Srinivas Pandruvada srinivas.pandruv...@linux.intel.com
Note, that in the meantime the bmg160 driver just went all regmap
on us (as part of adding SPI support - though that step hasn't
happened yet). Hence we'll need a means of telling regmap about this
possibility.
Perhaps this is covered by a regmap_bulk_read()?
The series[1] I am working on implements a i2c smbus block data regmap
bus driver. Regmap should then automatically do a block read in
regmap_bulk_read.
Patch 15 introduces the i2c block data regmap bus driver[2].
I am only implementing this so I don't break bmc150 behavior. I do not
have the hardware available to test this regmap driver so it would be great
if someone else could test one of the next versions of this bus driver.
Best regards,
Markus
[1] http://thread.gmane.org/gmane.linux.kernel/2018643
[2] http://thread.gmane.org/gmane.linux.kernel/2018639
---
drivers/iio/gyro/bmg160.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/drivers/iio/gyro/bmg160.c b/drivers/iio/gyro/bmg160.c
index b2a6ccb..1ff306d 100644
--- a/drivers/iio/gyro/bmg160.c
+++ b/drivers/iio/gyro/bmg160.c
@@ -772,6 +772,7 @@ static const struct iio_event_spec bmg160_event = {
.sign = 's',\
.realbits = 16, \
.storagebits = 16, \
+ .endianness = IIO_LE, \
}, \
.event_spec = bmg160_event,\
.num_event_specs = 1\
@@ -809,19 +810,16 @@ static irqreturn_t bmg160_trigger_handler(int irq,
void *p)
struct iio_poll_func *pf = p;
struct iio_dev *indio_dev = pf-indio_dev;
struct bmg160_data *data = iio_priv(indio_dev);
- int bit, ret, i = 0;
+ int ret = 0;
mutex_lock(data-mutex);
- for (bit = 0; bit AXIS_MAX; bit++) {
- ret = i2c_smbus_read_word_data(data-client,
- BMG160_AXIS_TO_REG(bit));
- if (ret 0) {
- mutex_unlock(data-mutex);
- goto err;
- }
- data-buffer[i++] = ret;
- }
+ ret = i2c_smbus_read_i2c_block_data_or_emulated(data-client,
+ BMG160_REG_XOUT_L,
+ AXIS_MAX * 2,
+ (u8 *)data-buffer);
mutex_unlock(data-mutex);
+ if (ret 0)
+ goto err;
iio_push_to_buffers_with_timestamp(indio_dev, data-buffer,
pf-timestamp);
--
To unsubscribe from this list: send the line unsubscribe linux-iio in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
signature.asc
Description: Digital signature
[PATCH v4 0/5] Altera PCIe host controller driver with MSI support
This is the 4th version of patch set to add support for Altera PCIe host controller with MSI feature on Altera FPGA device families. This patchset mainly resolve comments from Marc Zyngier in v3. It is based on patch series from Marc Zyngier Per-device MSI domain platform MSI [1] to get rid of struct msi_controller. v3-v4 changes: - pcie-altera: change to incremental count for loop - pcie-altera: add udelay when polling - pcie-altera: return -ENOMEM for irq_domain_add_linear error - pcie-altera-msi: add WARN_ON(nr_irq) != 1 - update error handling for platform_get_resource_byname History: --- [v1]: https://lkml.org/lkml/2015/7/28/395 [v2]: https://lkml.org/lkml/2015/7/31/267 [v3]: http://www.kernelhub.org/?msg=811940p=2 Ley Foon Tan (5): arm: add msi.h to Kbuild pci:host: Add Altera PCIe host controller driver pci: altera: Add Altera PCIe MSI driver Documentation: dt-bindings: pci: altera pcie device tree binding MAINTAINERS: Add Altera PCIe and MSI drivers maintainer .../devicetree/bindings/pci/altera-pcie-msi.txt| 27 + .../devicetree/bindings/pci/altera-pcie.txt| 49 ++ MAINTAINERS| 16 + arch/arm/include/asm/Kbuild| 1 + drivers/pci/host/Kconfig | 15 + drivers/pci/host/Makefile | 2 + drivers/pci/host/pcie-altera-msi.c | 322 drivers/pci/host/pcie-altera.c | 543 + 8 files changed, 975 insertions(+) create mode 100644 Documentation/devicetree/bindings/pci/altera-pcie-msi.txt create mode 100644 Documentation/devicetree/bindings/pci/altera-pcie.txt create mode 100644 drivers/pci/host/pcie-altera-msi.c create mode 100644 drivers/pci/host/pcie-altera.c -- 1.8.2.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 1/3] staging: wilc1000: code style: fix macro with multiple statements
On Sun, Aug 16, 2015 at 01:30:12AM -0400, Raphaël Beamonte wrote:
#define MALLOC_WILC_BUFFER(name, size) \
- exported_ ## name = kmalloc(size, GFP_KERNEL);\
- if (!exported_ ## name) { \
- printk(fail to alloc: %s memory\n, exported_ ## name); \
- return -ENOBUFS;\
- }
+ do { \
+ exported_ ## name = kmalloc(size, GFP_KERNEL);\
+ if (!exported_ ## name) { \
+ printk(fail to alloc: %s memory\n, exported_ ##
name); \
+ return -ENOBUFS;\
+ }
+ } while (0)
Pull it in one indent level... But actually this macro has a return in
the middle of it, so it just introduces bugs all over the place like
eating cookies in bed. We should just delete it instead.
regards,
dan carpenter
--
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/3] Introduce usb charger framework to deal with the usb gadget power negotation
On Mon, Aug 17, 2015 at 02:02:08PM +0800, Baolin Wang wrote: On 17 August 2015 at 09:15, Li Jun b47...@freescale.com wrote: On Fri, Aug 14, 2015 at 07:04:56PM +0800, Baolin Wang wrote: On 14 August 2015 at 16:55, Li Jun b47...@freescale.com wrote: Hi Baolin, On Fri, Aug 14, 2015 at 05:47:43PM +0800, Baolin Wang wrote: Currently the Linux kernel does not provide any standard integration of this feature that integrates the USB subsystem with the system power regulation provided by PMICs meaning that either vendors must add this in their kernels or USB gadget devices based on Linux (such as mobile phones) may not behave as they should. Providing a standard framework for doing this in the kernel. Why not add power supply class support into this? Hi Jun, We don't need the power supply class support into the usb charger, I suppose usb charger is also a power supply for the system, we can use power supply class framework for notify mechanism and get/set many attributes(maybe also the current limit), I see those usb charger drivers under ./driver/power/ are designed with power supply supported. I don't think so. The usb charger is rely on the usb gadget, which is not a complete power supply device and it combines the usb and the power supply. Thus we make it into usb gadget system. Thanks. Why it cannot be a complete power supply device? I was thinking this framework can cover it, I have no doubt on putting this framework into gadget system, but still can't understand why we don't need power supply class at all for a usb charger, or you think introduce power supply into usb gadget is not a right direction from code structure point view? Li Jun Li Jun just introduce the notify mechanism for power to set the current limit when notifying some events from usb charger. Maybe I misunderstand your meanings, please describe it detailedly. Thanks for your comments. Li Jun -- Baolin.wang Best Regards -- Baolin.wang Best Regards -- 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] ASoC: tegra: Convert to managed resources
On Mon, Aug 17, 2015 at 12:47 PM, Alexandre Courbot gnu...@gmail.com wrote:
On Thu, Aug 13, 2015 at 4:29 PM, Vaishali Thakkar
vthakkar1...@gmail.com wrote:
Use managed resource functions devm_clk_put and
devm_snd_soc_register_component to simplify error handling.
To be compatible with the change various gotos are replaced
with direct returns, and unneeded labels are dropped.
Signed-off-by: Vaishali Thakkar vthakkar1...@gmail.com
---
sound/soc/tegra/tegra20_spdif.c | 37 +
1 file changed, 13 insertions(+), 24 deletions(-)
diff --git a/sound/soc/tegra/tegra20_spdif.c
b/sound/soc/tegra/tegra20_spdif.c
index 9141477..f69b2e4 100644
--- a/sound/soc/tegra/tegra20_spdif.c
+++ b/sound/soc/tegra/tegra20_spdif.c
@@ -273,45 +273,40 @@ static int tegra20_spdif_platform_probe(struct
platform_device *pdev)
GFP_KERNEL);
if (!spdif) {
dev_err(pdev-dev, Can't allocate tegra20_spdif\n);
- ret = -ENOMEM;
- goto err;
+ return -ENOMEM;
}
dev_set_drvdata(pdev-dev, spdif);
- spdif-clk_spdif_out = clk_get(pdev-dev, spdif_out);
+ spdif-clk_spdif_out = devm_clk_get(pdev-dev, spdif_out);
if (IS_ERR(spdif-clk_spdif_out)) {
pr_err(Can't retrieve spdif clock\n);
ret = PTR_ERR(spdif-clk_spdif_out);
- goto err;
+ return ret;
Maybe do return PTR_ERR(spdif-clk_spdif_out); for consistency with
the other error cases of this function?
}
mem = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!mem) {
dev_err(pdev-dev, No memory resource\n);
- ret = -ENODEV;
- goto err_clk_put;
+ return -ENODEV;
}
dmareq = platform_get_resource(pdev, IORESOURCE_DMA, 0);
if (!dmareq) {
dev_err(pdev-dev, No DMA resource\n);
- ret = -ENODEV;
- goto err_clk_put;
+ return -ENODEV;
}
memregion = devm_request_mem_region(pdev-dev, mem-start,
resource_size(mem), DRV_NAME);
if (!memregion) {
dev_err(pdev-dev, Memory region already claimed\n);
- ret = -EBUSY;
- goto err_clk_put;
+ return -EBUSY;
}
regs = devm_ioremap(pdev-dev, mem-start, resource_size(mem));
if (!regs) {
dev_err(pdev-dev, ioremap failed\n);
- ret = -ENOMEM;
- goto err_clk_put;
+ return -ENOMEM;
}
spdif-regmap = devm_regmap_init_mmio(pdev-dev, regs,
@@ -319,7 +314,7 @@ static int tegra20_spdif_platform_probe(struct
platform_device *pdev)
if (IS_ERR(spdif-regmap)) {
dev_err(pdev-dev, regmap init failed\n);
ret = PTR_ERR(spdif-regmap);
- goto err_clk_put;
+ return ret;
Same here.
Actually people prefer to write this way when they are calling PTR_ERR
more than one time for the same value. But as for this file at both places
we are calling PTR_ERR for different values, may be we can directly call
it in return.
}
spdif-playback_dma_data.addr = mem-start + TEGRA20_SPDIF_DATA_OUT;
@@ -334,8 +329,9 @@ static int tegra20_spdif_platform_probe(struct
platform_device *pdev)
goto err_pm_disable;
}
- ret = snd_soc_register_component(pdev-dev,
tegra20_spdif_component,
- tegra20_spdif_dai, 1);
+ ret = devm_snd_soc_register_component(pdev-dev,
+ tegra20_spdif_component,
+ tegra20_spdif_dai, 1);
if (ret) {
dev_err(pdev-dev, Could not register DAI: %d\n, ret);
ret = -ENOMEM;
@@ -345,21 +341,17 @@ static int tegra20_spdif_platform_probe(struct
platform_device *pdev)
ret = tegra_pcm_platform_register(pdev-dev);
if (ret) {
dev_err(pdev-dev, Could not register PCM: %d\n, ret);
- goto err_unregister_component;
+ return ret;
In the previous code, PM cleanup was also performed after the
component was unregistered. If you return directly, this is not
performed anymore - I think you should goto err_suspend; here.
This will change the ordering of cleanup operations though - e.g.
snd_soc_unregister_component() will now be called *after* PM cleanup.
Are things still working ok after this? (I suppose they do considering
how simple the PM ops are, but it might be worth testing).
I think you are right. I missed that. But now thing is , this patch is already
applied here:
https://git.kernel.org/cgit/linux/kernel/git/broonie/sound.git/commit/?h=topic/tegra
I am not
Re: [PATCH] mmc: dw_mmc: fix pio mode when internal dmac is enabled
On 3 August 2015 at 17:04, Heiko Stübner he...@sntech.de wrote:
The dw_mci_init_dma() may decide to not use dma, but pio instead, caused
by things like wrong dma settings in the system.
Till now the code dw_mci_init_slot() always assumed that dma is available
when CONFIG_MMC_DW_IDMAC was defined, ignoring the host-use_dma var
set during dma init.
So when now the dma init failed for whatever reason, the transfer sizes
would still be set for dma transfers, especially including the maximum
block-count calculated from host-ring_size and resulting in a
[4.991109] [ cut here ]
[4.99] kernel BUG at drivers/mmc/core/core.c:256!
[4.991113] Internal error: Oops - BUG: 0 [#1] SMP ARM
because host-ring_size is 0 in this case and the slot init code uses
the wrong code to calculate the values.
Fix this by selecting the correct calculations using the host-use_dma
variable instead of the CONFIG_MMC_DW_IDMAC config option.
Signed-off-by: Heiko Stuebner he...@sntech.de
---
drivers/mmc/host/dw_mmc.c | 27 ++-
1 file changed, 14 insertions(+), 13 deletions(-)
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 40e9d8e..9ec3521 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -2391,19 +2391,20 @@ static int dw_mci_init_slot(struct dw_mci *host,
unsigned int id)
mmc-max_seg_size = host-pdata-blk_settings-max_seg_size;
} else {
/* Useful defaults if platform data is unset. */
-#ifdef CONFIG_MMC_DW_IDMAC
- mmc-max_segs = host-ring_size;
- mmc-max_blk_size = 65536;
- mmc-max_seg_size = 0x1000;
- mmc-max_req_size = mmc-max_seg_size * host-ring_size;
- mmc-max_blk_count = mmc-max_req_size / 512;
-#else
- mmc-max_segs = 64;
- mmc-max_blk_size = 65536; /* BLKSIZ is 16 bits */
- mmc-max_blk_count = 512;
- mmc-max_req_size = mmc-max_blk_size * mmc-max_blk_count;
- mmc-max_seg_size = mmc-max_req_size;
-#endif /* CONFIG_MMC_DW_IDMAC */
+ if (host-use_dma) {
+ mmc-max_segs = host-ring_size;
I expect this may cause a compiler error since host-ring_size is only
available in the struct dw_mci *host when CONFIG_MMC_DW_IDMAC is set.
I have already pulled in this patch from Jaehoon's pull request.
Perhaps I should only amend the patch and change the host-ring_size
to be always available no matter if CONFIG_MMC_DW_IDMAC is set or not?
+ mmc-max_blk_size = 65536;
+ mmc-max_seg_size = 0x1000;
+ mmc-max_req_size = mmc-max_seg_size *
host-ring_size;
+ mmc-max_blk_count = mmc-max_req_size / 512;
+ } else {
+ mmc-max_segs = 64;
+ mmc-max_blk_size = 65536; /* BLKSIZ is 16 bits */
+ mmc-max_blk_count = 512;
+ mmc-max_req_size = mmc-max_blk_size *
+ mmc-max_blk_count;
+ mmc-max_seg_size = mmc-max_req_size;
+ }
}
if (dw_mci_get_cd(mmc))
--
2.1.4
Kind regards
Uffe
--
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 Aug 17
Hi all, Changes since 20150813: Dropped tree: drm-exynos The pci tree gained a conflict against the arm-soc tree. The v4l-dvb tree still had its build failure so I used the version from next-20150810. The pm tree gained a conflict against the samsung tree. The thermal-soc tree gained a conflict against the arm tree. The drm tree gained conflicts against the drm-intel-fixes tree. The drm-panel tree gained a conflict against the tegra tree. The drm-exynos tree gained a build failure so I dropped it for today. The block tree gained a conflict against Linus' tree. The md tree gained conflicts against the block tree. The security tree gained a build failure that was fixed by installing libssl-dev. The tip tree gained a conflict against Linus' tree. The staging tree gained conflicts against the rdma tree. The akpm-current tree still had its build failure for which I reverted 2 commits. Non-merge commits (relative to Linus' tree): 7694 6937 files changed, 400211 insertions(+), 162615 deletions(-) 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 and checkout or reset to the new master. 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, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 224 trees (counting Linus' and 33 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . 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. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (8916e0b03ec3 Merge tag 'armsoc-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc) Merging fixes/master (c7e9ad7da219 Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on module install) Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify) Merging arm-current/fixes (09edea4f8fde ARM: 8410/1: VDSO: fix coarse clock monotonicity regression) Merging m68k-current/for-linus (1214c525484c m68k: Use for_each_sg()) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-fixes/fixes (f7644cbfcdf0 Linux 4.2-rc6) Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2) Merging sparc/master (73958c651fbf sparc64: use ENTRY/ENDPROC in VISsave) Merging net/master (83fccfc3940c inet: fix potential deadlock in reqsk_queue_unlink()) Merging ipsec/master (158cd4af8ded packet: missing dev_put() in packet_do_bind()) Merging sound-current/for-linus (7ccb0a9917a5 ALSA: hda - Fix the white noise on Dell laptop) Merging pci-current/for-linus (c9ddbac9c891 PCI: Restore PCI_MSIX_FLAGS_BIRMASK definition) Merging wireless-drivers/master (741e3b9902d1 rtlwifi: rtl8723be: Add module parameter for MSI interrupts) Merging driver-core.current/driver-core-linus (cbfe8fa6cd67 Linux 4.2-rc4) Merging tty.current/tty-linus (cbfe8fa6cd67 Linux 4.2-rc4) Merging usb.current/usb-linus (f7644cbfcdf0 Linux 4.2-rc6) Merging usb-gadget-fixes/fixes (c93e64e91248 usb: udc: core: add device_del() call to error pathway) Merging usb-serial-fixes/usb-linus (74472233233f USB: sierra: add 1199:68AB device ID) Merging staging.current/staging-linus (f7644cbfcdf0 Linux 4.2-rc6) Merging char-misc.current/char-misc-linus (f7644cbfcdf0 Linux 4.2-rc6) Merging input-current/for-linus (6b30c73e9f37 Input: elantech - add special check for fw_version 0x470f01 touchpad) Merging crypto-current/master (b310c178e6d8 crypto: caam - fix memory corruption in ahash_final_ctx) Merging ide/master (d681f1166919 ide: remove deprecated use of pci api) Merging devicetree-current/devicetree/merge (f76502aa9140
