RE: [PATCH v3 1/2] i2c: add DMA support for freescale i2c driver

[Yao Yuan]

On Wednesday, March 26, 2014 at 11:43:27 AM, Marek Vasut wrote:
> On Wednesday, March 26, 2014 at 04:08:27 AM, Yao Yuan wrote:
> 
> [...]
> 
> > > > +   i2c_imx->use_dma = false;
> > > > +   } else if (i2c_imx_dma_request(i2c_imx, (dma_addr_t)phy_addr))
> {
> > > > +   dev_info(>dev,
> > > > +   "can't request dma chan, faild use 
> > > > dma.\n");
> > > > +   i2c_imx->use_dma = false;
> > > > +   } else {
> > > > +   i2c_imx->use_dma = true;
> > > > +   }
> > >
> > > Can you not just check if i2c_imx->dma is valid pointer or NULL
> pointer ?
> > > Then you won't need a separate variable, for this purpose ... right ?
> >
> > Sorry and I think what I know is just to check whether it is NULL.
> > Then for the second question, maybe there are some other ways, But I
> > think it is more tidy and easier understanding for using a separate
> > variable, for this purpose.
> 
> You are just wasting space and duplicating data, unless I am wrong.
> 

Well, Do you have a better idea? Although I think it's necessary.


Best regards,
Yuan Yao
N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

[PATCH] staging: silicom: hide conditionally used function in condition

[SeongJae Park]

bp_proc_create() be called only when BP_PROC_SUPPORT defined but its
definition live outside of #ifdef BP_PROC_SUPPORT and cause following
trivial build warning:
drivers/staging/silicom/bpctl_mod.c:6786:12: warning:
‘bp_proc_create’ defined but not used [-Wunused-function]
 static int bp_proc_create(void)
^

Fix the warning by hide the definition inside #ifdef BP_PROC_SUPPORT.

Signed-off-by: SeongJae Park 
---
 drivers/staging/silicom/bpctl_mod.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/staging/silicom/bpctl_mod.c 
b/drivers/staging/silicom/bpctl_mod.c
index 6b9365b..beff280 100644
--- a/drivers/staging/silicom/bpctl_mod.c
+++ b/drivers/staging/silicom/bpctl_mod.c
@@ -119,7 +119,9 @@ static void if_scan_init(void);
 
 static int bypass_proc_create_dev_sd(struct bpctl_dev *pbp_device_block);
 static int bypass_proc_remove_dev_sd(struct bpctl_dev *pbp_device_block);
+#ifdef BP_PROC_SUPPORT
 static int bp_proc_create(void);
+#endif
 
 static int is_bypass_fn(struct bpctl_dev *pbpctl_dev);
 static int get_dev_idx_bsf(int bus, int slot, int func);
@@ -6783,6 +6785,7 @@ EXPORT_SYMBOL(bp_if_scan_sd);
 
 static struct proc_dir_entry *bp_procfs_dir;
 
+#ifdef BP_PROC_SUPPORT
 static int bp_proc_create(void)
 {
bp_procfs_dir = proc_mkdir(BP_PROC_DIR, init_net.proc_net);
@@ -6794,6 +6797,7 @@ static int bp_proc_create(void)
}
return 0;
 }
+#endif
 
 static int procfs_add(char *proc_name, const struct file_operations *fops,
  struct bpctl_dev *dev)
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: fs: gpf in simple_setattr

[Dave Jones]

On Tue, Mar 25, 2014 at 10:12:29PM +0100, Jan Kara wrote:

 > This fixes an oops triggered by trinity when it tried mounting
 > anon_inodefs which overwrote anon_inode_inode pointer while other CPU
 > has been in anon_inode_getfile() between ihold() and d_instantiate().
 > Thus effectively creating dentry pointing to an inode without holding a
 > reference to it.
 


Sasha, do you have changes to trinity's syscall/mount.c ?
It's kind of miraculous we managed to get the type arg right
there, because right now we're just passing a random address as an arg.
The only way that could work is if we randomly managed to do an allocation,
and then a seek & read from /proc/filesystems to that buffer.  If you're
lucky enough to get all those conditions right from rand() calls, you should
probably give up on kernel hacking and buy some powerball tickets.

We should add some code to make that only return strings from /proc/filesystems,
which makes me wonder if you already did that..

Dave

--
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 v6] can: xilinx CAN controller support

[Joe Perches]

On Wed, 2014-03-26 at 10:56 +0530, Kedareswara rao Appana wrote:
> This patch adds xilinx CAN controller support.
> This driver supports both ZYNQ CANPS and Soft IP
> AXI CAN controller.

Just trivial notes about dmesg logging output.

> diff --git a/drivers/net/can/xilinx_can.c b/drivers/net/can/xilinx_can.c
[]
> +static int set_reset_mode(struct net_device *ndev)
> +{
[]
> + netdev_warn(ndev, "timedout waiting for config mode\n");

timed out

> +static int xcan_set_bittiming(struct net_device *ndev)
> +{
[]
> + if (!is_config_mode) {
> + netdev_alert(ndev,
> + "BUG! Cannot set bittiming can is notin config mode\n");

"Cannot set bit timing - CAN is not in config mode\n"

> +static int xcan_chip_start(struct net_device *ndev)
> +{

> + netdev_warn(ndev,
> + "time out waiting for correct mode\n");

Please be consistent.  Maybe
"timed out waiting for correct mode\n"

> +static int xcan_open(struct net_device *ndev)
> +{
> + struct xcan_priv *priv = netdev_priv(ndev);
> + int ret;
> +
> + ret = request_irq(ndev->irq, xcan_interrupt, priv->irq_flags,
> + ndev->name, ndev);
> + if (ret < 0) {
> + netdev_err(ndev, "Irq allocation for CAN failed\n");

irq is almost always lower case.


--
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: gpf in simple_setattr

[Jan Kara]

On Tue 25-03-14 17:41:59, Linus Torvalds wrote:
> On Tue, Mar 25, 2014 at 2:12 PM, Jan Kara  wrote:
> >
> >   Can you try whether the following patch fixes the issue for you?
> 
> Good catch, Honza.
> 
> I hate how fragile that code ends up being and would love to see that
> "anon_inode_inode" allocation and assignment just once in
> anon_inode_init(), but considering that it wants the superblock
> pointer, I suspect it's not cleanly doable. Oh well. Your patch looks
> like it should make the issue moot, I just dread this happening again
> due to the layout of the code.
  Well, I think it could be done relatively cleanly... How about the
attached patch (it boots for me)?

Honza
-- 
Jan Kara 
SUSE Labs, CR
>From de87b1e6c3613d92f659c632be57461e87828e42 Mon Sep 17 00:00:00 2001
From: Jan Kara 
Date: Wed, 26 Mar 2014 06:20:14 +0100
Subject: [PATCH] vfs: Allocate anon_inode_inode in anon_inode_init()

Currently we allocated anon_inode_inode in anon_inodefs_mount. This is
somewhat fragile as if that function ever gets called again, it will
overwrite anon_inode_inode pointer. So move the initialization of
anon_inode_inode to anon_inode_init().

Signed-off-by: Jan Kara 
---
 fs/anon_inodes.c | 22 +++---
 1 file changed, 7 insertions(+), 15 deletions(-)

diff --git a/fs/anon_inodes.c b/fs/anon_inodes.c
index 4b4543b8b894..7f34f7702204 100644
--- a/fs/anon_inodes.c
+++ b/fs/anon_inodes.c
@@ -41,19 +41,8 @@ static const struct dentry_operations anon_inodefs_dentry_operations = {
 static struct dentry *anon_inodefs_mount(struct file_system_type *fs_type,
 int flags, const char *dev_name, void *data)
 {
-	struct dentry *root;
-	root = mount_pseudo(fs_type, "anon_inode:", NULL,
+	return mount_pseudo(fs_type, "anon_inode:", NULL,
 			_inodefs_dentry_operations, ANON_INODE_FS_MAGIC);
-	if (!IS_ERR(root)) {
-		struct super_block *s = root->d_sb;
-		anon_inode_inode = alloc_anon_inode(s);
-		if (IS_ERR(anon_inode_inode)) {
-			dput(root);
-			deactivate_locked_super(s);
-			root = ERR_CAST(anon_inode_inode);
-		}
-	}
-	return root;
 }
 
 static struct file_system_type anon_inode_fs_type = {
@@ -180,12 +169,15 @@ static int __init anon_inode_init(void)
 	anon_inode_mnt = kern_mount(_inode_fs_type);
 	if (IS_ERR(anon_inode_mnt)) {
 		error = PTR_ERR(anon_inode_mnt);
-		goto err_unregister_filesystem;
+		goto err_exit;
+	}
+	anon_inode_inode = alloc_anon_inode(anon_inode_mnt->mnt_sb);
+	if (IS_ERR(anon_inode_inode)) {
+		error = PTR_ERR(anon_inode_inode);
+		goto err_exit;
 	}
 	return 0;
 
-err_unregister_filesystem:
-	unregister_filesystem(_inode_fs_type);
 err_exit:
 	panic(KERN_ERR "anon_inode_init() failed (%d)\n", error);
 }
-- 
1.8.1.4

Re: [PATCH v4 0/5] KVM: x86: flush tlb out of mmu-lock after write protection

[Hu Yaohui]

Hi Guangrong,
Thanks a lot!
I will reopen a new discussion next time.
Does that means once the level 1 guest page table entry is modified,
the host should make a decision in page fault handler whether the page
sync or unsync?
My question is that since all level 1 guest page tables are writable,
when the entry in the page table is modified. there is no page fault
will happen, how can the mmu_need_write_protect to be called to make
whether sync or unsync decision?
Thanks for your time!

Best Wishes,
Yaohui

On Wed, Mar 26, 2014 at 1:07 AM, Xiao Guangrong
 wrote:
> On 03/26/2014 12:40 PM, Hu Yaohui wrote:
>> Hi all,
>> I hope you have a good day!
>> I have debugged the code myself. I have called dump_stack() in
>> function "__kvm_unsync_page"
>> and function "invlpg".  Actually every time before invlpg is called,
>> the page fault handled will call "__kvm_unsync_page" before invlpg to
>> mark the specified sp as unsynced. (correct me if I am wrong). I am
>> wondering why there is a page fault. AFAIK when calling flush_tlb_page
>> in the guest os. it will issue invlpg instruction directly, I did not
>> see any operation which could always cause the page fault.I would
>> really appreciate if if someone could shed me some lights on it.
>> Thanks for your time!
>
> Page fault is used to map a page into guest and set the proper permission
> on for it so this is the right place to make decision if the page need be
> writable.
>
> Tlb flush is used when guest wants to have a clean tlb so that host syncs the
> unsync page tables when it is happing.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6] can: xilinx CAN controller support

[Kedareswara rao Appana]

This patch adds xilinx CAN controller support.
This driver supports both ZYNQ CANPS and Soft IP
AXI CAN controller.

Signed-off-by: Kedareswara rao Appana 
---
This patch is rebased on the 3.14 rc8 kernel
Chnages for v6:
- Updated the driver with review comments.
- Used the clock names specified in the IP data sheet.
- Updated the devicetree bindings doc as per Rob suggestion.
Changes for v5:
- Updated the driver with the review comments.
- Remove the check for the tx fifo full interrupt condition
  form Tx interrupt routine as we are checking it in the _xmit
  routine.
- Clearing the txok interrupt in the tx interrupt routine for
  every Tx can frame.
Changes for v4:
- Added check for the tx fifo full interrupt condition in
  Tx interrupt routine.
- Added be iohelper functions.
- Moved the clock enable/disable to probe/remove because of
  Added big endian support for AXI CAN controller case(reading
  a register during probe for that we need to enable clock).
Changes for v3:
- Updated the driver with the review comments.
- Modified the tranmit logic as per Marc suggestion.
- Enabling the clock when the interface is up to reduce the
  Power consumption.
Changes for v2:
- Updated with the review comments.
- Removed the unnecessary debug prints.
- include tx,rx fifo depths in ZYNQ CANPS case also.
---
 .../devicetree/bindings/net/can/xilinx_can.txt |   44 +
 drivers/net/can/Kconfig|7 +
 drivers/net/can/Makefile   |1 +
 drivers/net/can/xilinx_can.c   | 1179 
 4 files changed, 1231 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/can/xilinx_can.txt
 create mode 100644 drivers/net/can/xilinx_can.c

diff --git a/Documentation/devicetree/bindings/net/can/xilinx_can.txt 
b/Documentation/devicetree/bindings/net/can/xilinx_can.txt
new file mode 100644
index 000..4646396
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/xilinx_can.txt
@@ -0,0 +1,44 @@
+Xilinx Axi CAN/Zynq CANPS controller Device Tree Bindings
+-
+
+Required properties:
+- compatible   : Should be "xlnx,zynq-can-1.00.a" for Zynq CAN
+ controllers and "xlnx,axi-can-1.00.a" for Axi CAN
+ controllers.
+- reg  : Physical base address and size of the Axi CAN/Zynq
+ CANPS registers map.
+- interrupts   : Property with a value describing the interrupt
+ number.
+- interrupt-parent : Must be core interrupt controller
+- clock-names  : List of input clock names - "can_clk", "pclk"
+ (For CANPS), "can_clk" , "s_axi_aclk"(For AXI CAN)
+ (See clock bindings for details).
+- clocks   : Clock phandles (see clock bindings for details).
+- tx-fifo-depth: Can Tx fifo depth.
+- rx-fifo-depth: Can Rx fifo depth.
+
+
+Example:
+
+For Zynq CANPS Dts file:
+   zynq_can_0: can@e0008000 {
+   compatible = "xlnx,zynq-can-1.00.a";
+   clocks = < 19>, < 36>;
+   clock-names = "can_clk", "pclk";
+   reg = <0xe0008000 0x1000>;
+   interrupts = <0 28 4>;
+   interrupt-parent = <>;
+   tx-fifo-depth = <0x40>;
+   rx-fifo-depth = <0x40>;
+   };
+For Axi CAN Dts file:
+   axi_can_0: axi-can@4000 {
+   compatible = "xlnx,axi-can-1.00.a";
+   clocks = < 0>;
+   clock-names = "can_clk","s_axi_aclk" ;
+   reg = <0x4000 0x1>;
+   interrupt-parent = <>;
+   interrupts = <0 59 1>;
+   tx-fifo-depth = <0x40>;
+   rx-fifo-depth = <0x40>;
+   };
diff --git a/drivers/net/can/Kconfig b/drivers/net/can/Kconfig
index 9e7d95d..9049884 100644
--- a/drivers/net/can/Kconfig
+++ b/drivers/net/can/Kconfig
@@ -125,6 +125,13 @@ config CAN_GRCAN
  endian syntheses of the cores would need some modifications on
  the hardware level to work.
 
+config CAN_XILINXCAN
+   tristate "Xilinx CAN"
+   depends on ARCH_ZYNQ || MICROBLAZE || COMPILE_TEST
+   depends on COMMON_CLK && HAS_IOMEM
+   ---help---
+ Xilinx CAN driver. This driver supports both soft AXI CAN IP and
+ Zynq CANPS IP.
 source "drivers/net/can/mscan/Kconfig"
 
 source "drivers/net/can/sja1000/Kconfig"
diff --git a/drivers/net/can/Makefile b/drivers/net/can/Makefile
index c744039..0b8e11e 100644
--- a/drivers/net/can/Makefile
+++ b/drivers/net/can/Makefile
@@ -25,5 +25,6 @@ obj-$(CONFIG_CAN_JANZ_ICAN3)  += janz-ican3.o
 obj-$(CONFIG_CAN_FLEXCAN)  += flexcan.o
 obj-$(CONFIG_PCH_CAN)  += pch_can.o

[PATCH net] virtio-net: correct error handling of virtqueue_kick()

[Jason Wang]

Current error handling of virtqueue_kick() was wrong in two places:
- The skb were freed immediately when virtqueue_kick() fail during
  xmit. This may lead double free since the skb was not detached from
  the virtqueue.
- try_fill_recv() returns false when virtqueue_kick() fail. This will
  lead unnecessary rescheduling of refill work.

Actually, it's safe to just ignore the kick failure in those two
places. So this patch fixes this by partially revert commit
67975901183799af8e93ec60e322f9e2a1940b9b.

Fixes 67975901183799af8e93ec60e322f9e2a1940b9b
(virtio_net: verify if virtqueue_kick() succeeded).

Cc: Heinz Graalfs 
Cc: Rusty Russell 
Cc: Michael S. Tsirkin 
Signed-off-by: Jason Wang 
---
 drivers/net/virtio_net.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 5632a99..841b608 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -671,8 +671,7 @@ static bool try_fill_recv(struct receive_queue *rq, gfp_t 
gfp)
if (err)
break;
} while (rq->vq->num_free);
-   if (unlikely(!virtqueue_kick(rq->vq)))
-   return false;
+   virtqueue_kick(rq->vq);
return !oom;
 }
 
@@ -877,7 +876,7 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct 
net_device *dev)
err = xmit_skb(sq, skb);
 
/* This should not happen! */
-   if (unlikely(err) || unlikely(!virtqueue_kick(sq->vq))) {
+   if (unlikely(err)) {
dev->stats.tx_fifo_errors++;
if (net_ratelimit())
dev_warn(>dev,
@@ -886,6 +885,7 @@ static netdev_tx_t start_xmit(struct sk_buff *skb, struct 
net_device *dev)
kfree_skb(skb);
return NETDEV_TX_OK;
}
+   virtqueue_kick(sq->vq);
 
/* Don't wait up for transmitted skbs to be freed. */
skb_orphan(skb);
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 0/5] KVM: x86: flush tlb out of mmu-lock after write protection

[Xiao Guangrong]

On 03/26/2014 12:40 PM, Hu Yaohui wrote:
> Hi all,
> I hope you have a good day!
> I have debugged the code myself. I have called dump_stack() in
> function "__kvm_unsync_page"
> and function "invlpg".  Actually every time before invlpg is called,
> the page fault handled will call "__kvm_unsync_page" before invlpg to
> mark the specified sp as unsynced. (correct me if I am wrong). I am
> wondering why there is a page fault. AFAIK when calling flush_tlb_page
> in the guest os. it will issue invlpg instruction directly, I did not
> see any operation which could always cause the page fault.I would
> really appreciate if if someone could shed me some lights on it.
> Thanks for your time!

Page fault is used to map a page into guest and set the proper permission
on for it so this is the right place to make decision if the page need be
writable.

Tlb flush is used when guest wants to have a clean tlb so that host syncs the
unsync page tables when it is happing.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] pwm-backlight: switch to gpiod interface (part 1)

[Alexandre Courbot]

Ping Thierry, can you have a look at this series? It is quite similar
to the same change you merged for panel-simple (although I cannot see
it in -next neither).

On Thu, Feb 27, 2014 at 2:53 PM, Alexandre Courbot  wrote:
> These two patches initiate the switch of the pwm-backlight driver to
> the gpiod GPIO interface, as it considerably simplifies the code.
>
> For compatibility with current users of the driver, it is still possible
> to pass the enable GPIO number as platform data. Two platforms are still
> relying on this feature (pxa/palmtc and shmobile/armadillo800eva) which
> will be removed as soon as its last users are switched to GPIO mapping
> tables.
>
> Alexandre Courbot (2):
>   ARM: SAMSUNG: remove gpio flags in dev-backlight
>   pwm-backlight: switch to gpiod interface
>
>  arch/arm/plat-samsung/dev-backlight.c |  2 -
>  drivers/video/backlight/pwm_bl.c  | 72 
> +++
>  include/linux/pwm_backlight.h |  5 +--
>  3 files changed, 32 insertions(+), 47 deletions(-)
>
> --
> 1.9.0
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-gpio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] input: misc: Add driver for Intel Bay Trail GPIO buttons

[Zhu, Lejun]

This patch adds support for the GPIO buttons on some Intel Bay Trail
tablets originally running Windows 8. The ACPI description of these
buttons follows "Windows ACPI Design Guide for SoC Platforms".

Signed-off-by: Lejun Zhu 
---
 drivers/input/misc/Kconfig   |  10 ++
 drivers/input/misc/Makefile  |   1 +
 drivers/input/misc/baytrail_button.c | 198
+++
 3 files changed, 209 insertions(+)
 create mode 100644 drivers/input/misc/baytrail_button.c

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 7904ab0..bb6fe2e 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -666,4 +666,14 @@ config INPUT_IDEAPAD_SLIDEBAR
  To compile this driver as a module, choose M here: the
  module will be called ideapad_slidebar.

+config INPUT_BAYTRAIL_BUTTON
+   tristate "Intel Baytrail Buttons"
+   depends on KEYBOARD_GPIO
+   help
+ Say Y here if you have a Baytrail tablet that is compatible
+ with Windows ACPI Design Guide.
+
+ To compile this driver as a module, choose M here: the
+ module will be called baytrail_button.
+
 endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index cda71fc..c3d6a68 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -63,3 +63,4 @@ obj-$(CONFIG_INPUT_WM831X_ON) += wm831x-on.o
 obj-$(CONFIG_INPUT_XEN_KBDDEV_FRONTEND)+= xen-kbdfront.o
 obj-$(CONFIG_INPUT_YEALINK)+= yealink.o
 obj-$(CONFIG_INPUT_IDEAPAD_SLIDEBAR)   += ideapad_slidebar.o
+obj-$(CONFIG_INPUT_BAYTRAIL_BUTTON)+= baytrail_button.o
diff --git a/drivers/input/misc/baytrail_button.c
b/drivers/input/misc/baytrail_button.c
new file mode 100644
index 000..e4829e1
--- /dev/null
+++ b/drivers/input/misc/baytrail_button.c
@@ -0,0 +1,198 @@
+/*
+ * baytrail_button.c: supports the GPIO buttons on some Baytrail
+ * tablets.
+ *
+ * (C) Copyright 2014 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; version 2
+ * of the License.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static void byt_button_device_release(struct device *);
+
+/*
+ * Definition of buttons on the tablet. The ACPI index of each button
+ * is defined in "Windows ACPI Design Guide for SoC Platforms"
+ */
+#defineMAX_NBUTTONS5
+
+struct byt_button_info {
+   const char *name;
+   int acpi_index;
+   unsigned int event_code;
+   int repeat;
+   int wakeup;
+   int gpio;
+};
+
+static struct byt_button_info byt_button_tbl[] = {
+   {"power", 0, KEY_POWER, 0, 1, -1},
+   {"home", 1, KEY_HOME, 0, 1, -1},
+   {"volume_up", 2, KEY_VOLUMEUP, 1, 0, -1},
+   {"volume_down", 3, KEY_VOLUMEDOWN, 1, 0, -1},
+   {"rotation_lock", 4, KEY_RO, 0, 0, -1},
+};
+
+/*
+ * Some of the buttons like volume up/down are auto repeat, while others
+ * are not. To support both, we register two gpio-keys device, and put
+ * buttons into them based on whether the key should be auto repeat.
+ */
+#defineBUTTON_TYPES2
+
+static struct gpio_keys_button byt_buttons[BUTTON_TYPES][MAX_NBUTTONS];
+
+static struct gpio_keys_platform_data byt_button_data[BUTTON_TYPES] = {
+   {
+   .buttons= byt_buttons[0],
+   .nbuttons   = 0,
+   .rep= 0
+   },
+   {
+   .buttons= byt_buttons[1],
+   .nbuttons   = 0,
+   .rep= 1
+   }
+};
+
+static struct platform_device byt_button_device[BUTTON_TYPES] = {
+   {
+   .name   = "gpio-keys",
+   .id = PLATFORM_DEVID_AUTO,
+   .dev= {
+   .release= byt_button_device_release,
+   .platform_data  = _button_data[0],
+   }
+   },
+   {
+   .name   = "gpio-keys",
+   .id = PLATFORM_DEVID_AUTO,
+   .dev= {
+   .release= byt_button_device_release,
+   .platform_data  = _button_data[1],
+   }
+   }
+};
+
+/*
+ * Get the Nth GPIO number from the ACPI object.
+ */
+static int byt_button_lookup_gpio(struct device *dev, int acpi_index)
+{
+   struct gpio_desc *desc;
+   int ret;
+
+   desc = gpiod_get_index(dev, KBUILD_MODNAME, acpi_index);
+
+   if (IS_ERR(desc))
+   return -1;
+
+   ret = desc_to_gpio(desc);
+
+   gpiod_put(desc);
+
+   return ret;
+}
+
+static int byt_button_pnp_probe(struct pnp_dev *pdev,
+   const struct pnp_device_id *id)
+{
+   int i, j, r, ret;
+   int sz_tbl = sizeof(byt_button_tbl) / sizeof(byt_button_tbl[0]);
+   struct 

Re: [PATCH v4 0/5] KVM: x86: flush tlb out of mmu-lock after write protection

[Xiao Guangrong]

A suggestion: please send a new mail to ask question, especially,
when your question is not related to the patches, so that others
will probably discover the topic and join the discussion.

On 03/26/2014 12:25 AM, Hu Yaohui wrote:
> Hi Guangrong,
> Since you have written in the kvm/mmu.txt.
> 
> 
>   unsync:
> If true, then the translations in this page may not match the guest's
> translation.  This is equivalent to the state of the tlb when a pte is
> changed but before the tlb entry is flushed.  Accordingly, unsync ptes
> are synchronized when the guest executes invlpg or flushes its tlb by
> other means.  Valid for leaf pages.
> 
> 
> 
> This make sense to me, my question is when those unsync bits will be
> set? When the guest writes to the level 1 guest page tables, it will
> not cause a page fault. Those unsync bit is unlikely to be set when
> the entry is modified. (correct me if I am wrong).

The bit is set in mmu_need_write_protect() where the host makes decision
if the page need to be write-protected (!unsync) or to be unsynced.

--
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] Remove CONFIG_DCACHE_WORD_ACCESS

[Joe Perches]

On Wed, 2014-03-12 at 07:37 +1100, Benjamin Herrenschmidt wrote:
> On Tue, 2014-03-04 at 12:23 -0800, Joe Perches wrote:
> > It seems to duplicate CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> > so use that instead.
> > 
> > This changes the !CPU_LITTLE_ENDIAN powerpc arch to use unaligned
> > accesses in fs/dcache.c and fs/namei.c as
> > CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS is enabled for that arch.
> > 
> > Remove the now unused DCACHE_WORD_ACCESS defines & uses.
> 
> Interesting.. we have word-at-a-time but we never enabled
> DCACHE_WORD_ACCESS, I wonder why that is. In fact, we should
> probably do it for LE as well for P8 if we can make a P8
> only config option...
> 
> Anton, what do you reckon here ?

Anton, do you have an opinion here?

> Cheers,
> Ben.
> 
> > Signed-off-by: Joe Perches 
> > ---
> >  arch/arm/Kconfig  | 1 -
> >  arch/arm/include/asm/word-at-a-time.h | 4 ++--
> >  arch/arm64/Kconfig| 1 -
> >  arch/x86/Kconfig  | 1 -
> >  fs/Kconfig| 4 
> >  fs/dcache.c   | 2 +-
> >  fs/namei.c| 2 +-
> >  7 files changed, 4 insertions(+), 11 deletions(-)
> > 
> > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> > index 623a272..d5a2e60 100644
> > --- a/arch/arm/Kconfig
> > +++ b/arch/arm/Kconfig
> > @@ -12,7 +12,6 @@ config ARM
> > select BUILDTIME_EXTABLE_SORT if MMU
> > select CLONE_BACKWARDS
> > select CPU_PM if (SUSPEND || CPU_IDLE)
> > -   select DCACHE_WORD_ACCESS if HAVE_EFFICIENT_UNALIGNED_ACCESS
> > select GENERIC_ATOMIC64 if (CPU_V7M || CPU_V6 || !CPU_32v6K || !AEABI)
> > select GENERIC_CLOCKEVENTS_BROADCAST if SMP
> > select GENERIC_IDLE_POLL_SETUP
> > diff --git a/arch/arm/include/asm/word-at-a-time.h 
> > b/arch/arm/include/asm/word-at-a-time.h
> > index a6d0a29..778b2ad 100644
> > --- a/arch/arm/include/asm/word-at-a-time.h
> > +++ b/arch/arm/include/asm/word-at-a-time.h
> > @@ -54,7 +54,7 @@ static inline unsigned long find_zero(unsigned long mask)
> >  #include 
> >  #endif
> >  
> > -#ifdef CONFIG_DCACHE_WORD_ACCESS
> > +#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> >  
> >  /*
> >   * Load an unaligned word from kernel space.
> > @@ -94,5 +94,5 @@ static inline unsigned long load_unaligned_zeropad(const 
> > void *addr)
> > return ret;
> >  }
> >  
> > -#endif /* DCACHE_WORD_ACCESS */
> > +#endif /* HAVE_EFFICIENT_UNALIGNED_ACCESS */
> >  #endif /* __ASM_ARM_WORD_AT_A_TIME_H */
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index 764d682..2d6978c 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -13,7 +13,6 @@ config ARM64
> > select CLONE_BACKWARDS
> > select COMMON_CLK
> > select CPU_PM if (SUSPEND || CPU_IDLE)
> > -   select DCACHE_WORD_ACCESS
> > select GENERIC_CLOCKEVENTS
> > select GENERIC_CLOCKEVENTS_BROADCAST if SMP
> > select GENERIC_IOMAP
> > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> > index abb261e..60cfa073 100644
> > --- a/arch/x86/Kconfig
> > +++ b/arch/x86/Kconfig
> > @@ -98,7 +98,6 @@ config X86
> > select CLKEVT_I8253
> > select ARCH_HAVE_NMI_SAFE_CMPXCHG
> > select GENERIC_IOMAP
> > -   select DCACHE_WORD_ACCESS
> > select GENERIC_SMP_IDLE_THREAD
> > select ARCH_WANT_IPC_PARSE_VERSION if X86_32
> > select HAVE_ARCH_SECCOMP_FILTER
> > diff --git a/fs/Kconfig b/fs/Kconfig
> > index 312393f..7511271 100644
> > --- a/fs/Kconfig
> > +++ b/fs/Kconfig
> > @@ -4,10 +4,6 @@
> >  
> >  menu "File systems"
> >  
> > -# Use unaligned word dcache accesses
> > -config DCACHE_WORD_ACCESS
> > -   bool
> > -
> >  if BLOCK
> >  
> >  source "fs/ext2/Kconfig"
> > diff --git a/fs/dcache.c b/fs/dcache.c
> > index 265e0ce..4e3c195 100644
> > --- a/fs/dcache.c
> > +++ b/fs/dcache.c
> > @@ -163,7 +163,7 @@ int proc_nr_dentry(ctl_table *table, int write, void 
> > __user *buffer,
> >   * Compare 2 name strings, return 0 if they match, otherwise non-zero.
> >   * The strings are both count bytes long, and count is non-zero.
> >   */
> > -#ifdef CONFIG_DCACHE_WORD_ACCESS
> > +#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> >  
> >  #include 
> >  /*
> > diff --git a/fs/namei.c b/fs/namei.c
> > index 385f781..1ee33ca 100644
> > --- a/fs/namei.c
> > +++ b/fs/namei.c
> > @@ -1618,7 +1618,7 @@ static inline int nested_symlink(struct path *path, 
> > struct nameidata *nd)
> >   *   the final mask". Again, that could be replaced with a
> >   *   efficient population count instruction or similar.
> >   */
> > -#ifdef CONFIG_DCACHE_WORD_ACCESS
> > +#ifdef CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS
> >  
> >  #include 



--
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 0/5] KVM: x86: flush tlb out of mmu-lock after write protection

[Hu Yaohui]

Hi all,
I hope you have a good day!
I have debugged the code myself. I have called dump_stack() in
function "__kvm_unsync_page"
and function "invlpg".  Actually every time before invlpg is called,
the page fault handled will call "__kvm_unsync_page" before invlpg to
mark the specified sp as unsynced. (correct me if I am wrong). I am
wondering why there is a page fault. AFAIK when calling flush_tlb_page
in the guest os. it will issue invlpg instruction directly, I did not
see any operation which could always cause the page fault.I would
really appreciate if if someone could shed me some lights on it.
Thanks for your time!

Best Wishes,
Yaohui

On Tue, Mar 25, 2014 at 12:25 PM, Hu Yaohui  wrote:
> Hi Guangrong,
> Since you have written in the kvm/mmu.txt.
> 
>
>   unsync:
> If true, then the translations in this page may not match the guest's
> translation.  This is equivalent to the state of the tlb when a pte is
> changed but before the tlb entry is flushed.  Accordingly, unsync ptes
> are synchronized when the guest executes invlpg or flushes its tlb by
> other means.  Valid for leaf pages.
>
> 
>
> This make sense to me, my question is when those unsync bits will be
> set? When the guest writes to the level 1 guest page tables, it will
> not cause a page fault. Those unsync bit is unlikely to be set when
> the entry is modified. (correct me if I am wrong).
>
> 
> static void FNAME(invlpg)(struct kvm_vcpu *vcpu, gva_t gva)
> {
> ...
> for_each_shadow_entry(vcpu, gva, iterator) {
> level = iterator.level;
> sptep = iterator.sptep;
>
> sp = page_header(__pa(sptep));
> if (is_last_spte(*sptep, level)) {
> int offset, shift;
>
> if (!sp->unsync)
> break;
> ...
> 
> When guest called invlpg, kvm invlpg will navigate to to the last
> level,  if the sp->unsync is not set to 1, since the initial value is
> zero. it will just break. It's not straight forward to me that the
> specified sp will be synced with the guest page table.
>
> I think I have missed something or misunderstood the whole mechanism,
> I would really appreciate it if you could shed some lights on that.
>
> Best Wishes,
> Yaohui Hu
>
> On Mon, Mar 10, 2014 at 10:01 AM, Xiao Guangrong
>  wrote:
>> This patchset is splited from my previous patchset:
>> [PATCH v3 00/15] KVM: MMU: locklessly write-protect
>> that can be found at:
>> https://lkml.org/lkml/2013/10/23/265
>>
>> Changelog v4 :
>> - add more comments for patch 5 and thank for Marcelo's review
>>
>> Xiao Guangrong (5):
>>   Revert "KVM: Simplify kvm->tlbs_dirty handling"
>>   KVM: MMU: properly check last spte in fast_page_fault()
>>   KVM: MMU: lazily drop large spte
>>   KVM: MMU: flush tlb if the spte can be locklessly modified
>>   KVM: MMU: flush tlb out of mmu lock when write-protect the sptes
>>
>>  arch/x86/kvm/mmu.c | 72 
>> ++
>>  arch/x86/kvm/mmu.h | 14 +
>>  arch/x86/kvm/paging_tmpl.h |  7 ++---
>>  arch/x86/kvm/x86.c | 20 ++---
>>  include/linux/kvm_host.h   |  4 +--
>>  virt/kvm/kvm_main.c|  5 +++-
>>  6 files changed, 85 insertions(+), 37 deletions(-)
>>
>> --
>> 1.8.1.4
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 11/12] drm/nouveau: support GK20A in nouveau_accel_init()

[Ben Skeggs]

On Tue, Mar 25, 2014 at 9:10 AM, Thierry Reding
 wrote:
> On Mon, Mar 24, 2014 at 05:42:33PM +0900, Alexandre Courbot wrote:
>> GK20A does not embed a dedicated COPY engine and thus cannot allocate
>> the copy channel that nouveau_accel_init() attempts to create. It also
>> lacks any display hardware, so the creation of a software channel does
>> not apply neither.
>
> Perhaps this should be two separate patches?
>
>> diff --git a/drivers/gpu/drm/nouveau/nouveau_drm.c 
>> b/drivers/gpu/drm/nouveau/nouveau_drm.c
> [...]
>> + if (device->chipset == 0xea) {
>> + /* gk20a does not have CE0/CE1 */
>
> This would be another good candidate for a feature flag.
There are ways to query this in a chipset-independent way.  However,
despite reporting it as an error if no copy engines are available, the
code should continue on without the channel happily.  Perhaps we can
just punt the relevent error messages to a debug loglevel for now?

>
>> + arg0 = NVE0_CHANNEL_IND_ENGINE_GR;
>> + arg1 = 1;
>> + } else
>>   if (device->card_type >= NV_E0) {
>
> The formatting here is somewhat weird. From a brief look I couldn't find
> any indication that nouveau deviates from the standard coding style, so
> this should be:
>
> } else if (...) {
I use the former in a few places, despite it not entirely being
"correct".. It looks nicer though :)  I don't mind either way though.

>
>> + /* Need to figure out how to handle sw for gk20a */
>> + if (device->chipset == 0xea)
>> + goto skip_sw_init;
>
> The commit message makes it sound like SW isn't needed since gk20a
> "lacks any display hardware". In that case the comment here doesn't make
> much sense.
>
> Thierry
>
> ___
> 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: [Nouveau] [PATCH 12/12] drm/nouveau: support for probing GK20A

[Ben Skeggs]

On Mon, Mar 24, 2014 at 6:42 PM, Alexandre Courbot  wrote:
> Set the correct subdev/engine classes when GK20A (0xea) is probed.
>
> Signed-off-by: Alexandre Courbot 
> ---
>  drivers/gpu/drm/nouveau/core/engine/device/nve0.c | 20 
>  1 file changed, 20 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/core/engine/device/nve0.c 
> b/drivers/gpu/drm/nouveau/core/engine/device/nve0.c
> index 987edbc30a09..8509dd57de1f 100644
> --- a/drivers/gpu/drm/nouveau/core/engine/device/nve0.c
> +++ b/drivers/gpu/drm/nouveau/core/engine/device/nve0.c
> @@ -156,6 +156,26 @@ nve0_identify(struct nouveau_device *device)
> device->oclass[NVDEV_ENGINE_PPP] = _ppp_oclass;
> device->oclass[NVDEV_ENGINE_PERFMON] = _perfmon_oclass;
> break;
> +   case 0xea:
> +   device->cname = "GK20A";
> +   device->oclass[NVDEV_SUBDEV_MC ] =  nvc3_mc_oclass;
> +   device->oclass[NVDEV_SUBDEV_BUS] =  nvc0_bus_oclass;
> +   device->oclass[NVDEV_SUBDEV_TIMER  ] = _timer_oclass;
As per note on the PTIMER patch, can just switch this to
"gk20a_timer_oclass" on the latest code.

> +   device->oclass[NVDEV_SUBDEV_FB ] =  nvea_fb_oclass;
> +   device->oclass[NVDEV_SUBDEV_IBUS   ] = _ibus_oclass;
> +   device->oclass[NVDEV_SUBDEV_INSTMEM] = nv50_instmem_oclass;
> +   device->oclass[NVDEV_SUBDEV_VM ] = _vmmgr_oclass;
> +   device->oclass[NVDEV_SUBDEV_BAR] = _bar_oclass;
> +   device->oclass[NVDEV_ENGINE_DMAOBJ ] = _dmaeng_oclass;
> +   device->oclass[NVDEV_ENGINE_FIFO   ] =  nvea_fifo_oclass;
> +   /* TODO will need an implementation for this at some point... 
> */
> +#if 0
> +   device->oclass[NVDEV_ENGINE_SW ] =  nvc0_software_oclass;
> +#endif
> +   device->oclass[NVDEV_ENGINE_GR ] =  nvea_graph_oclass;
> +   device->oclass[NVDEV_ENGINE_COPY2  ] = _copy2_oclass;
> +   device->oclass[NVDEV_ENGINE_PERFMON] = _perfmon_oclass;
> +   break;
> case 0xf0:
> device->cname = "GK110";
> device->oclass[NVDEV_SUBDEV_VBIOS  ] = _bios_oclass;
> --
> 1.9.1
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 10/12] drm/nouveau/graph: add GK20A support

[Ben Skeggs]

On Mon, Mar 24, 2014 at 6:42 PM, Alexandre Courbot  wrote:
> Add a GR device for GK20A based on NVE4, with the correct classes
> definitions (GK20A's 3D class is 0xa297).
>
> Most of the NVE4 code can be used on GK20A, so make relevant bits of
> NVE4 available to other chips as well.
This will need a bit of a rebase on top of the tree I mentioned
earlier (also queued for drm-next now), where I've further split out
and named the various chunks of state.

Does GK104 match entirely correctly, or just happen to work?  I could
probably hunt down the GK20A netlist images and check that actually :)

>
> Signed-off-by: Alexandre Courbot 
> ---
>  drivers/gpu/drm/nouveau/Makefile   |  1 +
>  .../gpu/drm/nouveau/core/engine/graph/ctxnve4.c|  4 +-
>  drivers/gpu/drm/nouveau/core/engine/graph/nvc0.h   |  9 +++
>  drivers/gpu/drm/nouveau/core/engine/graph/nve4.c   |  2 +-
>  drivers/gpu/drm/nouveau/core/engine/graph/nvea.c   | 75 
> ++
>  .../gpu/drm/nouveau/core/include/engine/graph.h|  1 +
>  6 files changed, 89 insertions(+), 3 deletions(-)
>  create mode 100644 drivers/gpu/drm/nouveau/core/engine/graph/nvea.c
>
> diff --git a/drivers/gpu/drm/nouveau/Makefile 
> b/drivers/gpu/drm/nouveau/Makefile
> index 708d2e33835f..032a4744f843 100644
> --- a/drivers/gpu/drm/nouveau/Makefile
> +++ b/drivers/gpu/drm/nouveau/Makefile
> @@ -270,6 +270,7 @@ nouveau-y += core/engine/graph/nvc8.o
>  nouveau-y += core/engine/graph/nvd7.o
>  nouveau-y += core/engine/graph/nvd9.o
>  nouveau-y += core/engine/graph/nve4.o
> +nouveau-y += core/engine/graph/nvea.o
>  nouveau-y += core/engine/graph/nvf0.o
>  nouveau-y += core/engine/graph/nv108.o
>  nouveau-y += core/engine/mpeg/nv31.o
> diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/ctxnve4.c 
> b/drivers/gpu/drm/nouveau/core/engine/graph/ctxnve4.c
> index e2de73ee5eee..3904073f860d 100644
> --- a/drivers/gpu/drm/nouveau/core/engine/graph/ctxnve4.c
> +++ b/drivers/gpu/drm/nouveau/core/engine/graph/ctxnve4.c
> @@ -804,7 +804,7 @@ nve4_grctx_init_unk[] = {
> {}
>  };
>
> -static void
> +void
>  nve4_grctx_generate_mods(struct nvc0_graph_priv *priv, struct nvc0_grctx 
> *info)
>  {
> u32 magic[GPC_MAX][2];
> @@ -962,7 +962,7 @@ nve4_grctx_generate_main(struct nvc0_graph_priv *priv, 
> struct nvc0_grctx *info)
> nv_mask(priv, 0x41be10, 0x0080, 0x0080);
>  }
>
> -static struct nvc0_graph_init *
> +struct nvc0_graph_init *
>  nve4_grctx_init_hub[] = {
> nvc0_grctx_init_base,
> nve4_grctx_init_unk40xx,
> diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.h 
> b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.h
> index b0ab6de270b2..904f09b540c5 100644
> --- a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.h
> +++ b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.h
> @@ -221,6 +221,8 @@ void nvc0_grctx_generate_r418bb8(struct nvc0_graph_priv 
> *);
>  void nve4_grctx_generate_r418bb8(struct nvc0_graph_priv *);
>  void nvc0_grctx_generate_r406800(struct nvc0_graph_priv *);
>
> +void nve4_grctx_generate_mods(struct nvc0_graph_priv *, struct nvc0_grctx *);
> +
>  extern struct nouveau_oclass *nvc0_grctx_oclass;
>  extern struct nvc0_graph_init *nvc0_grctx_init_hub[];
>  extern struct nvc0_graph_init nvc0_grctx_init_base[];
> @@ -237,12 +239,17 @@ extern struct nvc0_graph_init nvc0_grctx_init_gpc_1[];
>  extern struct nvc0_graph_init nvc0_grctx_init_tpc[];
>  extern struct nvc0_graph_init nvc0_grctx_init_icmd[];
>  extern struct nvc0_graph_init nvd9_grctx_init_icmd[]; //
> +extern struct nvc0_graph_init nve4_grctx_init_icmd[];
> +
> +extern struct nvc0_graph_init *nve4_grctx_init_hub[];
> +extern struct nvc0_graph_init *nve4_grctx_init_gpc[];
>
>  extern struct nvc0_graph_mthd nvc0_grctx_init_mthd[];
>  extern struct nvc0_graph_init nvc0_grctx_init_902d[];
>  extern struct nvc0_graph_init nvc0_grctx_init_9039[];
>  extern struct nvc0_graph_init nvc0_grctx_init_90c0[];
>  extern struct nvc0_graph_init nvc0_grctx_init_mthd_magic[];
> +extern struct nvc0_graph_init nve4_grctx_init_a097[];
>
>  void nvc1_grctx_generate_mods(struct nvc0_graph_priv *, struct nvc0_grctx *);
>  void nvc1_grctx_generate_unkn(struct nvc0_graph_priv *);
> @@ -277,6 +284,8 @@ extern struct nvc0_graph_init nvf0_grctx_init_unk60xx[];
>
>  extern struct nouveau_oclass *nv108_grctx_oclass;
>
> +extern struct nvc0_graph_init *nve4_graph_init_mmio[];
> +
>  #define mmio_data(s,a,p) do {
>   \
> info->buffer[info->buffer_nr] = round_up(info->addr, (a));
>  \
> info->addr = info->buffer[info->buffer_nr++] + (s);   
>  \
> diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nve4.c 
> b/drivers/gpu/drm/nouveau/core/engine/graph/nve4.c
> index 05ec09c88517..442857c5c120 100644
> --- a/drivers/gpu/drm/nouveau/core/engine/graph/nve4.c
> +++ b/drivers/gpu/drm/nouveau/core/engine/graph/nve4.c
> @@ -298,7 +298,7 @@ nve4_graph_init(struct 

Re: [Nouveau] [PATCH 09/12] drm/nouveau/graph: pad firmware code at load time

[Ben Skeggs]

On Mon, Mar 24, 2014 at 6:42 PM, Alexandre Courbot  wrote:
> Pad the microcode to a multiple of 0x40, otherwise firmware will fail to
> run from non-prepadded firmware files.
>
> Signed-off-by: Alexandre Courbot 
> ---
>  drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c 
> b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
> index f997a18f5760..367e72daf8b1 100644
> --- a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
> +++ b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
> @@ -768,6 +768,10 @@ nvc0_graph_init_fw(struct nvc0_graph_priv *priv, u32 
> fuc_base,
> nv_wr32(priv, fuc_base + 0x0188, i >> 6);
> nv_wr32(priv, fuc_base + 0x0184, code->data[i]);
> }
> +
> +   /* code must be padded to 0x40 */
> +   for (; i < (((code->size / 4) + 0x3f) & ~0x3f); i++)
"for (; i & 0x3f; i++)" would work just as well :)

> +   nv_wr32(priv, fuc_base + 0x0184, 0);
>  }
>
>  static void
> --
> 1.9.1
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
--
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: [Nouveau] [PATCH 03/12] drm/nouveau/bar: only ioremap BAR3 if it exists

[Ben Skeggs]

On Tue, Mar 25, 2014 at 8:13 AM, Thierry Reding
 wrote:
> On Mon, Mar 24, 2014 at 05:42:25PM +0900, Alexandre Courbot wrote:
>> Some chips that use system memory exclusively (e.g. GK20A) do not
>> expose 2 BAR regions. For them only BAR1 exists, and it should be used
>> for USERD mapping. Do not map BAR3 if its resource does not exist.
>>
>> Signed-off-by: Alexandre Courbot 
>> ---
>>  drivers/gpu/drm/nouveau/core/subdev/bar/base.c | 7 +--
>>  1 file changed, 5 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/nouveau/core/subdev/bar/base.c 
>> b/drivers/gpu/drm/nouveau/core/subdev/bar/base.c
>> index bdf594116f3f..d713eeb75b13 100644
>> --- a/drivers/gpu/drm/nouveau/core/subdev/bar/base.c
>> +++ b/drivers/gpu/drm/nouveau/core/subdev/bar/base.c
>> @@ -110,6 +110,7 @@ nouveau_bar_create_(struct nouveau_object *parent,
>>  {
>>   struct nouveau_device *device = nv_device(parent);
>>   struct nouveau_bar *bar;
>> + bool has_bar3 = nv_device_resource_len(device, 3) != 0;
>
> I don't think this variable is really necessary since you only use the
> expression once anyway, but I don't feel very strongly about it, so
> either way:
I'd also prefer it folded in, but it's not a big deal.  A couple of
other upcoming comments will require a re-spin anyway, so we may as
well :)

>
> Reviewed-by: Thierry Reding 
>
> ___
> Nouveau mailing list
> nouv...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/nouveau
>
--
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 02/12] drm/nouveau/timer: skip calibration on GK20A

[Ben Skeggs]

On Tue, Mar 25, 2014 at 7:54 AM, Thierry Reding
 wrote:
> On Mon, Mar 24, 2014 at 05:42:24PM +0900, Alexandre Courbot wrote:
>> GK20A's timer is directly attached to the system timer and cannot be
>> calibrated. Skip the calibration phase on that chip since the
>> corresponding registers do not exist.
>>
>> Signed-off-by: Alexandre Courbot 
>> ---
>>  drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c | 19 +--
>>  1 file changed, 13 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c 
>> b/drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c
>> index c0bdd10358d7..822fe0d8a871 100644
>> --- a/drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c
>> +++ b/drivers/gpu/drm/nouveau/core/subdev/timer/nv04.c
>> @@ -185,6 +185,10 @@ nv04_timer_init(struct nouveau_object *object)
>>   if (ret)
>>   return ret;
>>
>> + /* gk20a does not have the calibration registers */
>> + if (device->chipset == 0xea)
>> + goto skip_clk_init;
>
> I'm concerned that this won't scale in the future. Perhaps a better
> solution would be to add a "flags" or "features" field to struct
> nouveau_device along with feature bits such as HAS_CALIBRATION or
> similar.
>
> That way we don't have to touch this code for every new future Tegra
> chip. Unless perhaps if there's a reason to expect things to change in
> newer generations.
I've already handled this in a slightly different way in the tree I'd
previously pointed Alex at (I think!), as I needed to do the same for
GM107.

Should just be able to use that implementation (so, just change the
probe patch) here too.

Thanks,
Ben.

>
> Thierry
>
> ___
> 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 08/12] drm/nouveau/graph: enable when using external firmware

[Ben Skeggs]

On Tue, Mar 25, 2014 at 8:58 AM, Thierry Reding
 wrote:
> On Mon, Mar 24, 2014 at 05:42:30PM +0900, Alexandre Courbot wrote:
> [...]
>> diff --git a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c 
>> b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
>> index 6ef8bf181b2d..f997a18f5760 100644
>> --- a/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
>> +++ b/drivers/gpu/drm/nouveau/core/engine/graph/nvc0.c
>> @@ -1133,10 +1133,14 @@ nvc0_graph_ctor(struct nouveau_object *parent, 
>> struct nouveau_object *engine,
>>   struct nvc0_graph_oclass *oclass = (void *)bclass;
>>   struct nouveau_device *device = nv_device(parent);
>>   struct nvc0_graph_priv *priv;
>> + bool use_fw;
>
> Perhaps "ext_fw" or "use_ext_fw" would be more accurate.
>
>>   int ret, i;
>>
>> + use_fw = nouveau_boolopt(device->cfgopt, "NvGrUseFW", false);
>> +
>>   ret = nouveau_graph_create(parent, engine, bclass,
>> -(oclass->fecs.ucode != NULL), );
>> +(oclass->fecs.ucode != NULL) || use_fw,
>> +);
>
> Or perhaps a more intuitive way would be to name the variable "enable"
> and have something like:
>
> if (!nouveau_boolopt(device->cfgopt, "NvGrUseFW", false))
> enable = oclass->fecs.ucode != NULL;
> else
> enable = true;
>
> ret = nouveau_graph_create(parent, engine, bclass, enable, );
> ...
Agreed, this looks a lot nicer.

>
> Thierry
>
> ___
> 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/

[for-next][PATCH 2/2] tracing: Add BUG_ON when stack end location is over written

[Steven Rostedt]

From: Aaron Tomlin 

It is difficult to detect a stack overrun when it
actually occurs.

We have observed that this type of corruption is often
silent and can go unnoticed. Once the corrupted region
is examined, the outcome is undefined and often
results in sporadic system crashes.

When the stack tracing feature is enabled, let's check
for this condition and take appropriate action.

Note: init_task doesn't get its stack end location
set to STACK_END_MAGIC.

Link: 
http://lkml.kernel.org/r/1395669837-30209-1-git-send-email-atom...@redhat.com

Signed-off-by: Aaron Tomlin 
Signed-off-by: Steven Rostedt 
---
 kernel/trace/trace_stack.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/trace/trace_stack.c b/kernel/trace/trace_stack.c
index e6be585..21b320e 100644
--- a/kernel/trace/trace_stack.c
+++ b/kernel/trace/trace_stack.c
@@ -13,6 +13,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -144,6 +145,8 @@ check_stack(unsigned long ip, unsigned long *stack)
i++;
}
 
+   BUG_ON(current != _task &&
+   *(end_of_stack(current)) != STACK_END_MAGIC);
  out:
arch_spin_unlock(_stack_lock);
local_irq_restore(flags);
-- 
1.8.5.3


--
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/

[for-next][PATCH 1/2] tracepoint: Remove unused API functions

[Steven Rostedt]

From: Mathieu Desnoyers 

After the following commit:

commit b75ef8b44b1cb95f5a26484b0e2fe37a63b12b44
Author: Mathieu Desnoyers 
Date:   Wed Aug 10 15:18:39 2011 -0400

Tracepoint: Dissociate from module mutex

The following functions became unnecessary:

- tracepoint_probe_register_noupdate,
- tracepoint_probe_unregister_noupdate,
- tracepoint_probe_update_all.

In fact, none of the in-kernel tracers, nor LTTng, nor SystemTAP use
them. Remove those.

Moreover, the functions:

- tracepoint_iter_start,
- tracepoint_iter_next,
- tracepoint_iter_stop,
- tracepoint_iter_reset.

are unused by in-kernel tracers, LTTng and SystemTAP. Remove those too.

Link: 
http://lkml.kernel.org/r/1395379142-2118-2-git-send-email-mathieu.desnoy...@efficios.com

Signed-off-by: Mathieu Desnoyers 
Signed-off-by: Steven Rostedt 
---
 include/linux/tracepoint.h |  18 
 kernel/tracepoint.c| 222 +
 2 files changed, 5 insertions(+), 235 deletions(-)

diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
index accc497..a3b2837 100644
--- a/include/linux/tracepoint.h
+++ b/include/linux/tracepoint.h
@@ -48,12 +48,6 @@ extern int tracepoint_probe_register(const char *name, void 
*probe, void *data);
 extern int
 tracepoint_probe_unregister(const char *name, void *probe, void *data);
 
-extern int tracepoint_probe_register_noupdate(const char *name, void *probe,
- void *data);
-extern int tracepoint_probe_unregister_noupdate(const char *name, void *probe,
-   void *data);
-extern void tracepoint_probe_update_all(void);
-
 #ifdef CONFIG_MODULES
 struct tp_module {
struct list_head list;
@@ -62,18 +56,6 @@ struct tp_module {
 };
 #endif /* CONFIG_MODULES */
 
-struct tracepoint_iter {
-#ifdef CONFIG_MODULES
-   struct tp_module *module;
-#endif /* CONFIG_MODULES */
-   struct tracepoint * const *tracepoint;
-};
-
-extern void tracepoint_iter_start(struct tracepoint_iter *iter);
-extern void tracepoint_iter_next(struct tracepoint_iter *iter);
-extern void tracepoint_iter_stop(struct tracepoint_iter *iter);
-extern void tracepoint_iter_reset(struct tracepoint_iter *iter);
-
 /*
  * tracepoint_synchronize_unregister must be called between the last tracepoint
  * probe unregistration and the end of module exit to make sure there is no
diff --git a/kernel/tracepoint.c b/kernel/tracepoint.c
index e2a58a2..65d9f94 100644
--- a/kernel/tracepoint.c
+++ b/kernel/tracepoint.c
@@ -67,10 +67,7 @@ struct tracepoint_entry {
 };
 
 struct tp_probes {
-   union {
-   struct rcu_head rcu;
-   struct list_head list;
-   } u;
+   struct rcu_head rcu;
struct tracepoint_func probes[0];
 };
 
@@ -83,7 +80,7 @@ static inline void *allocate_probes(int count)
 
 static void rcu_free_old_probes(struct rcu_head *head)
 {
-   kfree(container_of(head, struct tp_probes, u.rcu));
+   kfree(container_of(head, struct tp_probes, rcu));
 }
 
 static inline void release_probes(struct tracepoint_func *old)
@@ -91,7 +88,7 @@ static inline void release_probes(struct tracepoint_func *old)
if (old) {
struct tp_probes *tp_probes = container_of(old,
struct tp_probes, probes[0]);
-   call_rcu_sched(_probes->u.rcu, rcu_free_old_probes);
+   call_rcu_sched(_probes->rcu, rcu_free_old_probes);
}
 }
 
@@ -459,204 +456,11 @@ int tracepoint_probe_unregister(const char *name, void 
*probe, void *data)
 }
 EXPORT_SYMBOL_GPL(tracepoint_probe_unregister);
 
-static LIST_HEAD(old_probes);
-static int need_update;
-
-static void tracepoint_add_old_probes(void *old)
-{
-   need_update = 1;
-   if (old) {
-   struct tp_probes *tp_probes = container_of(old,
-   struct tp_probes, probes[0]);
-   list_add(_probes->u.list, _probes);
-   }
-}
-
-/**
- * tracepoint_probe_register_noupdate -  register a probe but not connect
- * @name: tracepoint name
- * @probe: probe handler
- * @data: probe private data
- *
- * caller must call tracepoint_probe_update_all()
- */
-int tracepoint_probe_register_noupdate(const char *name, void *probe,
-  void *data)
-{
-   struct tracepoint_func *old;
-
-   mutex_lock(_mutex);
-   old = tracepoint_add_probe(name, probe, data);
-   if (IS_ERR(old)) {
-   mutex_unlock(_mutex);
-   return PTR_ERR(old);
-   }
-   tracepoint_add_old_probes(old);
-   mutex_unlock(_mutex);
-   return 0;
-}
-EXPORT_SYMBOL_GPL(tracepoint_probe_register_noupdate);
-
-/**
- * tracepoint_probe_unregister_noupdate -  remove a probe but not disconnect
- * @name: tracepoint name
- * @probe: probe function pointer
- * @data: probe private data
- *
- * caller must call tracepoint_probe_update_all()
- */
-int tracepoint_probe_unregister_noupdate(const 

[PATCH] dm cache: remove unused function too_many_discard_blocks

[SeongJae Park]

Fix following trivial build warning:
drivers/md/dm-cache-target.c:2182:13: warning:
‘too_many_discard_blocks’ defined but not used [-Wunused-function]
 static bool too_many_discard_blocks(sector_t discard_block_size,
 ^

It's usage removed by ab1f4c35b7("dm cache: prevent corruption caused by
discard_block_size > cache_block_size") as work-around and the
definition was not removed though it was only one usage. Let's remove
the definition now for clean build result and get back the definition
again after the workarounded problem solved well.

Signed-off-by: SeongJae Park 
---
 drivers/md/dm-cache-target.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/md/dm-cache-target.c b/drivers/md/dm-cache-target.c
index 9f96e7a..2c1d347 100644
--- a/drivers/md/dm-cache-target.c
+++ b/drivers/md/dm-cache-target.c
@@ -2178,6 +2178,8 @@ static int create_cache_policy(struct cache *cache, 
struct cache_args *ca,
  */
 #define MAX_DISCARD_BLOCKS (1 << 14)
 
+#if 0
+/* FIXME: remove if 0 macro after stop-gap workaround solved */
 static bool too_many_discard_blocks(sector_t discard_block_size,
sector_t origin_size)
 {
@@ -2185,6 +2187,7 @@ static bool too_many_discard_blocks(sector_t 
discard_block_size,
 
return origin_size > MAX_DISCARD_BLOCKS;
 }
+#endif
 
 static sector_t calculate_discard_block_size(sector_t cache_block_size,
 sector_t origin_size)
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[for-next][PATCH 0/2] tracing: next updates

[Steven Rostedt]

  git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
for-next

Head SHA1: 3862807880acc0adaef6749738d210c9f45c3049


Aaron Tomlin (1):
  tracing: Add BUG_ON when stack end location is over written

Mathieu Desnoyers (1):
  tracepoint: Remove unused API functions


 include/linux/tracepoint.h |  18 
 kernel/trace/trace_stack.c |   3 +
 kernel/tracepoint.c| 222 +
 3 files changed, 8 insertions(+), 235 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/

[PATCH] tick, broadcast: Prevent false alarm when force mask contains offline cpus

[Preeti U Murthy]

Its possible that the tick_broadcast_force_mask contains cpus which are not
in cpu_online_mask when a broadcast tick occurs. This could happen under the
following circumstance assuming CPU1 is among the CPUs waiting for broadcast.

CPU0CPU1

Run CPU_DOWN_PREPARE notifiers

Start stop_machine  Gets woken up by IPI to run
stop_machine, sets itself in
tick_broadcast_force_mask if the
time of broadcast interrupt is around
the same time as this IPI.

Start stop_machine
  set_cpu_online(cpu1, false)
End stop_machineEnd stop_machine

Broadcast interrupt
  Finds that cpu1 in
  tick_broadcast_force_mask is offline
  and triggers the WARN_ON in
  tick_handle_oneshot_broadcast()

Clears all broadcast masks
in CPU_DEAD stage.

This WARN_ON was added to capture scenarios where the broadcast mask, be it
oneshot/pending/force_mask contain offline cpus whose tick devices have been
removed. But here is a case where we trigger the warn on in a valid scenario.

One could argue that the scenario is invalid and ought to be warned against
because ideally the broadcast masks need to be cleared of the cpus about to
go offine before clearing them in the online_mask so that we dont hit these
scenarios.

This would mean clearing the masks in CPU_DOWN_PREPARE stage. But
it is quite possible that this stage itself will fail and cpu hotplug will
not go through. We would then end up in a situation where the cpu has not gone
offline, and continues to wait for the broadcast interrupt like before.
  However it is cleared in the broadcast masks and this interrupt will never
be delivered. Hence clearing of masks is best kept off until we are sure that
the cpu is dead, i.e. in the CPU_DEAD stage.

Hence simply ensure that the tick_broadcast_force_mask is a subset of the
online cpus to take care of rare occurences such as above. Moreover this is
not a harmful scenario where the cpu is in the mask but its tick device was
shutdown. The WARN_ON will then continue to capture cases where we could
possibly cause a kernel crash.

Signed-off-by: Preeti U Murthy 
---

 kernel/time/tick-broadcast.c |7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/kernel/time/tick-broadcast.c b/kernel/time/tick-broadcast.c
index 63c7b2d..30b8731 100644
--- a/kernel/time/tick-broadcast.c
+++ b/kernel/time/tick-broadcast.c
@@ -606,7 +606,12 @@ again:
 */
cpumask_clear_cpu(smp_processor_id(), tick_broadcast_pending_mask);
 
-   /* Take care of enforced broadcast requests */
+   /* Take care of enforced broadcast requests. We could have offline
+* cpus in the tick_broadcast_force_mask. Thats ok, we got the interrupt
+* before we could clear the mask.
+*/
+   cpumask_and(tick_broadcast_force_mask,
+   tick_broadcast_force_mask, cpu_online_mask);
cpumask_or(tmpmask, tmpmask, tick_broadcast_force_mask);
cpumask_clear(tick_broadcast_force_mask);
 

--
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] ixen-netback: fix trivial printf format build warning

[SeongJae Park]

Fix following trivial build warning:

drivers/net/xen-netback/netback.c: In function ‘xenvif_tx_dealloc_action’:
drivers/net/xen-netback/netback.c:1585:8: warning:
format ‘%x’ expects argument of type
 ‘unsigned int’, but argument 3 has type ‘long int’ [-Wformat=]
gop - vif->tx_unmap_ops, ret);
^

Signed-off-by: SeongJae Park 
---
 drivers/net/xen-netback/netback.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/xen-netback/netback.c 
b/drivers/net/xen-netback/netback.c
index 5a8c4a4..90001b3 100644
--- a/drivers/net/xen-netback/netback.c
+++ b/drivers/net/xen-netback/netback.c
@@ -1574,7 +1574,7 @@ static inline void xenvif_tx_dealloc_action(struct xenvif 
*vif)
vif->pages_to_unmap,
gop - vif->tx_unmap_ops);
if (ret) {
-   netdev_err(vif->dev, "Unmap fail: nr_ops %x ret %d\n",
+   netdev_err(vif->dev, "Unmap fail: nr_ops %lx ret %d\n",
   gop - vif->tx_unmap_ops, ret);
for (i = 0; i < gop - vif->tx_unmap_ops; ++i) {
if (gop[i].status != GNTST_okay)
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next,v4] hyperv: Add support for virtual Receive Side Scaling (vRSS)

[Greg KH]

On Wed, Mar 26, 2014 at 03:23:47AM +, Haiyang Zhang wrote:
> 
> 
> > -Original Message-
> > From: David Miller [mailto:da...@davemloft.net]
> > Sent: Tuesday, March 25, 2014 8:47 PM
> > To: Haiyang Zhang
> > Cc: net...@vger.kernel.org; KY Srinivasan; o...@aepfle.de;
> > jasow...@redhat.com; linux-kernel@vger.kernel.org; driverdev-
> > de...@linuxdriverproject.org
> > Subject: Re: [PATCH net-next,v4] hyperv: Add support for virtual Receive
> > Side Scaling (vRSS)
> > 
> > From: David Miller 
> > Date: Tue, 25 Mar 2014 20:43:43 -0400 (EDT)
> > 
> > > From: Haiyang Zhang 
> > > Date: Tue, 25 Mar 2014 20:37:43 +
> > >
> > >> Do we know when the dependency (commit: 8a7206a89f) will be merged
> > >> into net-next tree?
> > >
> > > You're really not very patient, to say the least.
> > >
> > > It's done now and I'm working to integrate your patch.
> > >
> > > That patch has been in under review state in patchwork, which means
> > > that I will get to it at some point, so you don't need to worry about
> > > it any more than any other patch you might submit.
> > >
> > > The whole reason patchwork exists is so that people don't have to
> > > ask.
> > 
> > And actually, this dependency "8a7206a89f" commit doesn't exist
> > in the 'net' tree at all.  I just merged Linus's tree into 'net'
> > and it doesn't exist there either.
> > 
> > So this patch still doesn't compile.
> > 
> > I'm tossing it from patchwork until you sort this out.
> 
> Dave,
> 
> Thank you for the efforts.
> The commit is in the linux-next tree. You can see it from this link:
> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=8a7206a89f85c8439561b0eff85bb9440a2e97a9
> And, here is the commit log:
> 
> author
> K. Y. Srinivasan  2014-02-03 20:42:45 (GMT) 
> committer
> Greg Kroah-Hartman  2014-02-07 23:22:40 (GMT) 
> commit
> 8a7206a89f85c8439561b0eff85bb9440a2e97a9 (patch) 
> tree
> 61f763919607368481ac128f56416df1f49cd187 
> parent
> 011a7c3cc3aa60c7ea6bb49d847e80a299ba7b36 (diff) 
> 
> Drivers: hv: vmbus: Support per-channel driver state
> As we implement Virtual Receive Side Scaling on the networking side
> (the VRSS patches are currently under review), it will be useful to have
> per-channel state that vmbus drivers can manage. Add support for
> managing per-channel state.
> 
> KY:
> Do you know the original tree this patch was checked into by Greg KH? Or, 
> did Greg checked into linux-next tree directly?

No one "checks into the linux-next tree directly".

So your patch relies on a patch in my char-misc tree?  Ick, that wasn't
very wise.

It will just have to wait until the patch goes into 3.15-rc1, as my
trees are closed, sorry.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] staging: comedi: s626: use comedi_timeout() on remaining loops

[Chase Southwood]

There were just a handful of more while loops in this file that needed
timeouts, and this patch takes care of them.  One new callback is
introduced, and all of the proper comedi_timeout() calls are then used.

Signed-off-by: Chase Southwood 
---
2: s626_i2c_handshake_eoc() can be used in s626_initialize() as noted by
Ian.  So, s626_initialize_eoc() has been removed, and its uses swapped
for s626_i2c_handshake_eoc().

 drivers/staging/comedi/drivers/s626.c | 34 ++
 1 file changed, 26 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/comedi/drivers/s626.c 
b/drivers/staging/comedi/drivers/s626.c
index 95fadf3..865cf93 100644
--- a/drivers/staging/comedi/drivers/s626.c
+++ b/drivers/staging/comedi/drivers/s626.c
@@ -295,10 +295,24 @@ static void s626_debi_replace(struct comedi_device *dev, 
unsigned int addr,
 
 /* **  EEPROM ACCESS FUNCTIONS  ** */
 
+static int s626_i2c_handshake_eoc(struct comedi_device *dev,
+struct comedi_subdevice *s,
+struct comedi_insn *insn,
+unsigned long context)
+{
+   unsigned int status;
+
+   status = s626_mc_test(dev, S626_MC2_UPLD_IIC, S626_P_MC2);
+   if (status)
+   return 0;
+   return -EBUSY;
+}
+
 static uint32_t s626_i2c_handshake(struct comedi_device *dev, uint32_t val)
 {
struct s626_private *devpriv = dev->private;
unsigned int ctrl;
+   uint32_t ret;
 
/* Write I2C command to I2C Transfer Control shadow register */
writel(val, devpriv->mmio + S626_P_I2CCTRL);
@@ -308,8 +322,9 @@ static uint32_t s626_i2c_handshake(struct comedi_device 
*dev, uint32_t val)
 * wait for upload confirmation.
 */
s626_mc_enable(dev, S626_MC2_UPLD_IIC, S626_P_MC2);
-   while (!s626_mc_test(dev, S626_MC2_UPLD_IIC, S626_P_MC2))
-   ;
+   ret = comedi_timeout(dev, NULL, NULL, s626_i2c_handshake_eoc, 0);
+   if (ret)
+   return ret;
 
/* Wait until I2C bus transfer is finished or an error occurs */
do {
@@ -2029,8 +2044,9 @@ static int s626_ai_insn_read(struct comedi_device *dev,
/* Wait for the data to arrive in FB BUFFER 1 register. */
 
/* Wait for ADC done */
-   while (!(readl(devpriv->mmio + S626_P_PSR) & S626_PSR_GPIO2))
-   ;
+   ret = comedi_timeout(dev, s, insn, s626_ai_eoc, 0);
+   if (ret)
+   return ret;
 
/* Fetch ADC data from audio interface's input shift register. */
 
@@ -2681,8 +2697,9 @@ static int s626_initialize(struct comedi_device *dev)
writel(S626_I2C_CLKSEL | S626_I2C_ABORT,
   devpriv->mmio + S626_P_I2CSTAT);
s626_mc_enable(dev, S626_MC2_UPLD_IIC, S626_P_MC2);
-   while (!(readl(devpriv->mmio + S626_P_MC2) & S626_MC2_UPLD_IIC))
-   ;
+   ret = comedi_timeout(dev, NULL, NULL, s626_i2c_handshake_eoc, 0);
+   if (ret)
+   return ret;
 
/*
 * Per SAA7146 data sheet, write to STATUS
@@ -2691,8 +2708,9 @@ static int s626_initialize(struct comedi_device *dev)
for (i = 0; i < 2; i++) {
writel(S626_I2C_CLKSEL, devpriv->mmio + S626_P_I2CSTAT);
s626_mc_enable(dev, S626_MC2_UPLD_IIC, S626_P_MC2);
-   while (!s626_mc_test(dev, S626_MC2_UPLD_IIC, S626_P_MC2))
-   ;
+   ret = comedi_timeout(dev, NULL, NULL, s626_i2c_handshake_eoc, 
0);
+   if (ret)
+   return ret;
}
 
/*
-- 
1.8.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/2] i2c: add DMA support for freescale i2c driver

[Marek Vasut]

On Wednesday, March 26, 2014 at 04:08:27 AM, Yao Yuan wrote:

[...]

> > > + i2c_imx->use_dma = false;
> > > + } else if (i2c_imx_dma_request(i2c_imx, (dma_addr_t)phy_addr)) {
> > > + dev_info(>dev,
> > > + "can't request dma chan, faild use dma.\n");
> > > + i2c_imx->use_dma = false;
> > > + } else {
> > > + i2c_imx->use_dma = true;
> > > + }
> > 
> > Can you not just check if i2c_imx->dma is valid pointer or NULL pointer ?
> > Then you won't need a separate variable, for this purpose ... right ?
> 
> Sorry and I think what I know is just to check whether it is NULL.
> Then for the second question, maybe there are some other ways, But I think
> it is more tidy and easier understanding for using a separate variable,
> for this purpose.

You are just wasting space and duplicating data, unless I am wrong.

Best regards,
Marek Vasut
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH net-next,v4] hyperv: Add support for virtual Receive Side Scaling (vRSS)

[Haiyang Zhang]

> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Tuesday, March 25, 2014 8:47 PM
> To: Haiyang Zhang
> Cc: net...@vger.kernel.org; KY Srinivasan; o...@aepfle.de;
> jasow...@redhat.com; linux-kernel@vger.kernel.org; driverdev-
> de...@linuxdriverproject.org
> Subject: Re: [PATCH net-next,v4] hyperv: Add support for virtual Receive
> Side Scaling (vRSS)
> 
> From: David Miller 
> Date: Tue, 25 Mar 2014 20:43:43 -0400 (EDT)
> 
> > From: Haiyang Zhang 
> > Date: Tue, 25 Mar 2014 20:37:43 +
> >
> >> Do we know when the dependency (commit: 8a7206a89f) will be merged
> >> into net-next tree?
> >
> > You're really not very patient, to say the least.
> >
> > It's done now and I'm working to integrate your patch.
> >
> > That patch has been in under review state in patchwork, which means
> > that I will get to it at some point, so you don't need to worry about
> > it any more than any other patch you might submit.
> >
> > The whole reason patchwork exists is so that people don't have to
> > ask.
> 
> And actually, this dependency "8a7206a89f" commit doesn't exist
> in the 'net' tree at all.  I just merged Linus's tree into 'net'
> and it doesn't exist there either.
> 
> So this patch still doesn't compile.
> 
> I'm tossing it from patchwork until you sort this out.

Dave,

Thank you for the efforts.
The commit is in the linux-next tree. You can see it from this link:
http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=8a7206a89f85c8439561b0eff85bb9440a2e97a9
And, here is the commit log:

author
K. Y. Srinivasan  2014-02-03 20:42:45 (GMT) 
committer
Greg Kroah-Hartman  2014-02-07 23:22:40 (GMT) 
commit
8a7206a89f85c8439561b0eff85bb9440a2e97a9 (patch) 
tree
61f763919607368481ac128f56416df1f49cd187 
parent
011a7c3cc3aa60c7ea6bb49d847e80a299ba7b36 (diff) 

Drivers: hv: vmbus: Support per-channel driver state
As we implement Virtual Receive Side Scaling on the networking side
(the VRSS patches are currently under review), it will be useful to have
per-channel state that vmbus drivers can manage. Add support for
managing per-channel state.

KY:
Do you know the original tree this patch was checked into by Greg KH? Or, 
did Greg checked into linux-next tree directly?

Thanks,
- Haiyang

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH/v2] [trivial]treewide: Fix typo in printk

[Masanari Iida]

Fix spelling typo in printk from various part of kernel source.

Signed-off-by: Masanari Iida 
Acked-by: Arend van Spriel 
Acked-by: Randy Dunlap 

---
 arch/powerpc/platforms/powernv/opal.c | 2 +-
 drivers/i2c/busses/i2c-s3c2410.c  | 2 +-
 drivers/infiniband/hw/usnic/usnic_ib_qp_grp.c | 8 
 drivers/misc/mei/hw-txe.c | 2 +-
 drivers/net/bonding/bond_sysfs_slave.c| 2 +-
 drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c| 2 +-
 drivers/net/ethernet/qlogic/qlcnic/qlcnic_hw.c| 2 +-
 drivers/net/ethernet/via/via-velocity.c   | 2 +-
 drivers/net/wireless/brcm80211/brcmfmac/wl_cfg80211.c | 6 +++---
 drivers/scsi/qla2xxx/qla_nx2.c| 2 +-
 drivers/scsi/scsi_transport_fc.c  | 2 +-
 sound/soc/davinci/davinci-mcasp.c | 2 +-
 12 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/arch/powerpc/platforms/powernv/opal.c 
b/arch/powerpc/platforms/powernv/opal.c
index 2e269c2..7adcf62 100644
--- a/arch/powerpc/platforms/powernv/opal.c
+++ b/arch/powerpc/platforms/powernv/opal.c
@@ -275,7 +275,7 @@ static void opal_handle_message(void)
 
/* check for errors. */
if (ret) {
-   pr_warning("%s: Failed to retrive opal message, err=%lld\n",
+   pr_warning("%s: Failed to retrieve opal message, err=%lld\n",
__func__, ret);
return;
}
diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index ae44910..4bef480 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -244,7 +244,7 @@ static bool is_ack(struct s3c24xx_i2c *i2c)
}
usleep_range(1000, 2000);
}
-   dev_err(i2c->dev, "ack was not recieved\n");
+   dev_err(i2c->dev, "ack was not received\n");
return false;
 }
 
diff --git a/drivers/infiniband/hw/usnic/usnic_ib_qp_grp.c 
b/drivers/infiniband/hw/usnic/usnic_ib_qp_grp.c
index f8dfd76..f92e083 100644
--- a/drivers/infiniband/hw/usnic/usnic_ib_qp_grp.c
+++ b/drivers/infiniband/hw/usnic/usnic_ib_qp_grp.c
@@ -49,7 +49,7 @@ const char *usnic_ib_qp_grp_state_to_string(enum ib_qp_state 
state)
case IB_QPS_ERR:
return "ERR";
default:
-   return "UNKOWN STATE";
+   return "UNKNOWN STATE";
 
}
 }
@@ -506,12 +506,12 @@ int usnic_ib_qp_grp_modify(struct usnic_ib_qp_grp *qp_grp,
 
if (!status) {
qp_grp->state = new_state;
-   usnic_info("Transistioned %u from %s to %s",
+   usnic_info("Transitioned %u from %s to %s",
qp_grp->grp_id,
usnic_ib_qp_grp_state_to_string(old_state),
usnic_ib_qp_grp_state_to_string(new_state));
} else {
-   usnic_err("Failed to transistion %u from %s to %s",
+   usnic_err("Failed to transition %u from %s to %s",
qp_grp->grp_id,
usnic_ib_qp_grp_state_to_string(old_state),
usnic_ib_qp_grp_state_to_string(new_state));
@@ -672,7 +672,7 @@ usnic_ib_qp_grp_create(struct usnic_fwd_dev *ufdev, struct 
usnic_ib_vf *vf,
err = usnic_vnic_res_spec_satisfied(_transport_spec[transport],
res_spec);
if (err) {
-   usnic_err("Spec does not meet miniumum req for transport %d\n",
+   usnic_err("Spec does not meet minimum req for transport %d\n",
transport);
log_spec(res_spec);
return ERR_PTR(err);
diff --git a/drivers/misc/mei/hw-txe.c b/drivers/misc/mei/hw-txe.c
index f60182a..00d328d 100644
--- a/drivers/misc/mei/hw-txe.c
+++ b/drivers/misc/mei/hw-txe.c
@@ -781,7 +781,7 @@ static int mei_txe_hw_start(struct mei_device *dev)
 
ret = mei_txe_readiness_wait(dev);
if (ret < 0) {
-   dev_err(>pdev->dev, "wating for readiness failed\n");
+   dev_err(>pdev->dev, "waiting for readiness failed\n");
return ret;
}
 
diff --git a/drivers/net/bonding/bond_sysfs_slave.c 
b/drivers/net/bonding/bond_sysfs_slave.c
index 2e4eec5..a4de46b 100644
--- a/drivers/net/bonding/bond_sysfs_slave.c
+++ b/drivers/net/bonding/bond_sysfs_slave.c
@@ -36,7 +36,7 @@ static ssize_t state_show(struct slave *slave, char *buf)
case BOND_STATE_BACKUP:
return sprintf(buf, "backup\n");
default:
-   return sprintf(buf, "UNKONWN\n");
+   return sprintf(buf, "UNKNOWN\n");
}
 }
 static SLAVE_ATTR_RO(state);
diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c 
b/drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c
index db4280c..716fc37 100644
--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c
+++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_hw.c
@@ 

[PATCHv2 0/2] Add big endian support

[Xiubo Li]

This patches are preparing for Vybird, LS1 and LS2. And on LS1 the IP will
in BE mode.

And this has been test on Vybird.

Changes in V2:
- Add the detail information in the commit comment.
- 'big-endians' --> 'big-endian'.


Xiubo Li (2):
  watchdog: imx2_wdt: Sort the header files alphabetically
  watchdog: imx2_wdt: Add big-endian support

 drivers/watchdog/imx2_wdt.c | 52 -
 1 file changed, 37 insertions(+), 15 deletions(-)

-- 
1.8.4


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv2 1/2] watchdog: imx2_wdt: Sort the header files alphabetically

[Xiubo Li]

Signed-off-by: Xiubo Li 
Cc: Guenter Roeck 
---
 drivers/watchdog/imx2_wdt.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
index dd51d95..1795922 100644
--- a/drivers/watchdog/imx2_wdt.c
+++ b/drivers/watchdog/imx2_wdt.c
@@ -21,19 +21,19 @@
  * Halt on suspend:Manual  Can be automatic
  */
 
+#include 
+#include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #include 
-#include 
+#include 
+#include 
 
 #define DRIVER_NAME "imx2-wdt"
 
-- 
1.8.4


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv2 2/2] watchdog: imx2_wdt: Add big-endian support

[Xiubo Li]

For the platforms that this IP driver now supports:
SoCCPUWatchdog Need 'big-endian'?
--
Vybird little little   No
LS1little big  Yes
LS2little little   No
IMX+   little little   No

So for the LS1 SoCs, we need to do the big endianness converting.

And this will also support the following case, for example:
SoCCPUWatchdog Need 'big-endian'?
--
PowerPCbigbig  Yes

Signed-off-by: Xiubo Li 
Cc: Guenter Roeck 
---
 drivers/watchdog/imx2_wdt.c | 40 +++-
 1 file changed, 31 insertions(+), 9 deletions(-)

diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
index 1795922..32f8874 100644
--- a/drivers/watchdog/imx2_wdt.c
+++ b/drivers/watchdog/imx2_wdt.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -64,9 +65,26 @@ static struct {
void __iomem *base;
unsigned timeout;
unsigned long status;
+   bool big_endian;
struct timer_list timer;/* Pings the watchdog when closed */
 } imx2_wdt;
 
+static inline u16 imx2_wdt_readw(void __iomem *addr)
+{
+   if (imx2_wdt.big_endian)
+   return ioread16be(addr);
+   else
+   return ioread16(addr);
+}
+
+static inline void imx2_wdt_writew(u16 val, void __iomem *addr)
+{
+   if (imx2_wdt.big_endian)
+   iowrite16be(val, addr);
+   else
+   iowrite16(val, addr);
+}
+
 static struct miscdevice imx2_wdt_miscdev;
 
 static bool nowayout = WATCHDOG_NOWAYOUT;
@@ -87,7 +105,7 @@ static const struct watchdog_info imx2_wdt_info = {
 
 static inline void imx2_wdt_setup(void)
 {
-   u16 val = __raw_readw(imx2_wdt.base + IMX2_WDT_WCR);
+   u16 val = imx2_wdt_readw(imx2_wdt.base + IMX2_WDT_WCR);
 
/* Suspend timer in low power mode, write once-only */
val |= IMX2_WDT_WCR_WDZST;
@@ -100,17 +118,17 @@ static inline void imx2_wdt_setup(void)
/* Set the watchdog's Time-Out value */
val |= WDOG_SEC_TO_COUNT(imx2_wdt.timeout);
 
-   __raw_writew(val, imx2_wdt.base + IMX2_WDT_WCR);
+   imx2_wdt_writew(val, imx2_wdt.base + IMX2_WDT_WCR);
 
/* enable the watchdog */
val |= IMX2_WDT_WCR_WDE;
-   __raw_writew(val, imx2_wdt.base + IMX2_WDT_WCR);
+   imx2_wdt_writew(val, imx2_wdt.base + IMX2_WDT_WCR);
 }
 
 static inline void imx2_wdt_ping(void)
 {
-   __raw_writew(IMX2_WDT_SEQ1, imx2_wdt.base + IMX2_WDT_WSR);
-   __raw_writew(IMX2_WDT_SEQ2, imx2_wdt.base + IMX2_WDT_WSR);
+   imx2_wdt_writew(IMX2_WDT_SEQ1, imx2_wdt.base + IMX2_WDT_WSR);
+   imx2_wdt_writew(IMX2_WDT_SEQ2, imx2_wdt.base + IMX2_WDT_WSR);
 }
 
 static void imx2_wdt_timer_ping(unsigned long arg)
@@ -143,12 +161,12 @@ static void imx2_wdt_stop(void)
 
 static void imx2_wdt_set_timeout(int new_timeout)
 {
-   u16 val = __raw_readw(imx2_wdt.base + IMX2_WDT_WCR);
+   u16 val = imx2_wdt_readw(imx2_wdt.base + IMX2_WDT_WCR);
 
/* set the new timeout value in the WSR */
val &= ~IMX2_WDT_WCR_WT;
val |= WDOG_SEC_TO_COUNT(new_timeout);
-   __raw_writew(val, imx2_wdt.base + IMX2_WDT_WCR);
+   imx2_wdt_writew(val, imx2_wdt.base + IMX2_WDT_WCR);
 }
 
 static int imx2_wdt_open(struct inode *inode, struct file *file)
@@ -192,7 +210,7 @@ static long imx2_wdt_ioctl(struct file *file, unsigned int 
cmd,
return put_user(0, p);
 
case WDIOC_GETBOOTSTATUS:
-   val = __raw_readw(imx2_wdt.base + IMX2_WDT_WRSR);
+   val = imx2_wdt_readw(imx2_wdt.base + IMX2_WDT_WRSR);
new_value = val & IMX2_WDT_WRSR_TOUT ? WDIOF_CARDRESET : 0;
return put_user(new_value, p);
 
@@ -257,8 +275,12 @@ static struct miscdevice imx2_wdt_miscdev = {
 
 static int __init imx2_wdt_probe(struct platform_device *pdev)
 {
-   int ret;
+   struct device_node *np = pdev->dev.of_node;
struct resource *res;
+   int ret;
+
+   if (np)
+   imx2_wdt.big_endian = of_property_read_bool(np, "big-endian");
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
imx2_wdt.base = devm_ioremap_resource(>dev, res);
-- 
1.8.4


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH v3 1/2] i2c: add DMA support for freescale i2c driver

[Yao Yuan]

On Sunday, March 23, 2014 @ 11:50:00 AM, Marek Vasut wrote:
> On Thursday, March 13, 2014 at 02:47:56 AM, Yuan Yao wrote:
> > Add dma support for i2c. This function depend on DMA driver.
> > You can turn on it by write both the dmas and dma-name properties in
> > dts node.
> >
> > Signed-off-by: Yuan Yao 
> > ---
> >  drivers/i2c/busses/i2c-imx.c | 354
> > +-- 1 file changed, 306
> > insertions(+), 48 deletions(-)
> 
> Changelog is missing.

Sorry for this, Maybe the changelog is in the junk box. It's named "[PATCH v3 
0/2] i2c: add DMA support for freescale i2c driver". 

> [...]
> 
> > +/* Functions for DMA support */
> > +static int i2c_imx_dma_request(struct imx_i2c_struct *i2c_imx,
> > +   dma_addr_t phy_addr)
> > +{
> > +   struct imx_i2c_dma *dma = i2c_imx->dma;
> > +   struct dma_slave_config dma_sconfig;
> > +   struct device *dev = _imx->adapter.dev;
> > +   int ret;
> > +
> > +   dma->chan_tx = dma_request_slave_channel(dev, "tx");
> > +   if (!dma->chan_tx) {
> > +   dev_err(dev, "Dma tx channel request failed!\n");
> 
> DMA is written in all caps, it's an abbrev. for Direct Memory Access .
> Please fix globally.
> 

Ok, I will fix it globally.

> [...]
> 
> >  static int i2c_imx_write(struct imx_i2c_struct *i2c_imx, struct
> > i2c_msg
> > *msgs) {
> 
> [...]
> 
> > -   /* write data */
> > -   for (i = 0; i < msgs->len; i++) {
> > -   dev_dbg(_imx->adapter.dev,
> > -   "<%s> write byte: B%d=0x%X\n",
> > -   __func__, i, msgs->buf[i]);
> > -   imx_i2c_write_reg(msgs->buf[i], i2c_imx, IMX_I2C_I2DR);
> > +   temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2CR);
> > +   temp |= I2CR_DMAEN;
> > +   imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
> > +
> > +   /* write slave address */
> > +   imx_i2c_write_reg(msgs->addr << 1, i2c_imx, IMX_I2C_I2DR);
> > +   result = wait_for_completion_interruptible_timeout(
> > +   _imx->dma->cmd_complete,
> > +   msecs_to_jiffies(IMX_I2C_DMA_TIMEOUT));
> > +   if (result <= 0) {
> > +   dmaengine_terminate_all(dma->chan_using);
> > +   if (result)
> > +   return result;
> > +   else
> > +   return -ETIMEDOUT;
> > +   }
> > +
> > +   /* waiting for Transfer complete. */
> > +   while (timeout--) {
> > +   temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2SR);
> > +   if (temp & I2SR_ICF)
> > +   break;
> > +   udelay(10);
> > +   }
> 
> Do you ever check if this really timed out and handle such case at all ?
> I don't see it , but I might be wrong ...
> 

Oh, It's a bug, Thank you very much.

> > +   temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2CR);
> > +   temp &= ~I2CR_DMAEN;
> > +   imx_i2c_write_reg(temp, i2c_imx, IMX_I2C_I2CR);
> > +
> > +   /* write the last byte */
> > +   imx_i2c_write_reg(msgs->buf[msgs->len-1],
> > +   i2c_imx, IMX_I2C_I2DR);
> > result = i2c_imx_trx_complete(i2c_imx);
> > if (result)
> > return result;
> > +
> > result = i2c_imx_acked(i2c_imx);
> > if (result)
> > return result;
> > +   } else {
> > +   /* write slave address */
> > +   imx_i2c_write_reg(msgs->addr << 1, i2c_imx, IMX_I2C_I2DR);
> > +   result = i2c_imx_trx_complete(i2c_imx);
> > +   if (result)
> > +   return result;
> > +
> > +   result = i2c_imx_acked(i2c_imx);
> > +   if (result)
> > +   return result;
> > +
> > +   dev_dbg(_imx->adapter.dev, "<%s> write data\n", __func__);
> > +
> > +   /* write data */
> > +   for (i = 0; i < msgs->len; i++) {
> > +   dev_dbg(_imx->adapter.dev,
> > +   "<%s> write byte: B%d=0x%X\n",
> > +   __func__, i, msgs->buf[i]);
> 
> Can you not just have a variable $dev here and avoid having such a long
> noodle in the dev_dbg() call ?
> 

Ok, And I don't think the dev_dbg() is very helpful here now. 

> > +   imx_i2c_write_reg(msgs->buf[i], i2c_imx, IMX_I2C_I2DR);
> > +   result = i2c_imx_trx_complete(i2c_imx);
> > +   if (result)
> > +   return result;
> > +   result = i2c_imx_acked(i2c_imx);
> > +   if (result)
> > +   return result;
> > +   }
> > }
> > return 0;
> >  }
> [...]
> 
> > +   /* waiting for Transfer complete. */
> > +   while (timeout--) {
> > +   temp = imx_i2c_read_reg(i2c_imx, IMX_I2C_I2SR);
> 

Re: Linux 3.14-rc8 (LXC broken)

[Eric Paris]

On Tue, 2014-03-25 at 21:36 +0100, Andre Tomt wrote:
> *testing hat on*
> 
> PAM within namespaces (say, LXC) does not work anymore with 3.14-rc8,
> making login, ssh etc fail in containers unless you boot with audit=0.
> 
> This is due to a change in return value to user space; and is
> appearantly a known issue as evident in this earlier post from february:
> https://www.redhat.com/archives/linux-audit/2014-February/msg00087.html
> 
> Judging from the post it seems they want to ship 3.14 with this IMO
> quite serious regression? What is the namespace/container folks take on
> this?

Fair question.

Pam only worked in non-initial pid (or user) namespace if it was also in
the non-initial network namespace.  We added support for the network
namespace in 3.14.  So now PAM in the non-initial network namespace
functions the same as it would in the inital network namespace.  aka, it
fails.  This is actually what the audit userspace people think is the
right thing to happen.  You configured PAM to fail if it couldn't do the
right audit things, and it's failing.  Needing audit=0 is not new.

BUT given we broke (already broken [remember you configured PAM to fail
if audit didn't go well and it let you log in anyway?  aka broken?])
functionality adding network namespace support I'll send a request to
Linus tomorrow to rip out our network namespace support and I'll re-add
in 3.15 when we add pid (and partial user) namespace support.

-Eric

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] staging: vme: fix memory leak in vme_user_probe()

[Daeseok Youn]

If vme_master_request() returns NULL when it failed,
it need to free buffers for master.

And also removes unreachable code in vme_user_probe().

Signed-off-by: Daeseok Youn 
---
 drivers/staging/vme/devices/vme_user.c |9 +++--
 1 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/vme/devices/vme_user.c 
b/drivers/staging/vme/devices/vme_user.c
index 7927927..ffb4eee 100644
--- a/drivers/staging/vme/devices/vme_user.c
+++ b/drivers/staging/vme/devices/vme_user.c
@@ -776,7 +776,8 @@ static int vme_user_probe(struct vme_dev *vdev)
image[i].kern_buf = kmalloc(image[i].size_buf, GFP_KERNEL);
if (image[i].kern_buf == NULL) {
err = -ENOMEM;
-   goto err_master_buf;
+   vme_master_free(image[i].resource);
+   goto err_master;
}
}
 
@@ -819,8 +820,6 @@ static int vme_user_probe(struct vme_dev *vdev)
 
return 0;
 
-   /* Ensure counter set correcty to destroy all sysfs devices */
-   i = VME_DEVS;
 err_sysfs:
while (i > 0) {
i--;
@@ -830,12 +829,10 @@ err_sysfs:
 
/* Ensure counter set correcty to unalloc all master windows */
i = MASTER_MAX + 1;
-err_master_buf:
-   for (i = MASTER_MINOR; i < (MASTER_MAX + 1); i++)
-   kfree(image[i].kern_buf);
 err_master:
while (i > MASTER_MINOR) {
i--;
+   kfree(image[i].kern_buf);
vme_master_free(image[i].resource);
}
 
-- 
1.7.4.4


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/4] gpio: add IRQ chip helpers in gpiolib

[Alexandre Courbot]

On Tue, Mar 25, 2014 at 9:51 PM, Linus Walleij  wrote:
> This provides a function gpiochip_irqchip_add() to set
> up an irqchip for a GPIO controller, and a function
> gpiochip_set_chained_irqchip() to chain it to a parent
> irqchip.
>
> Most GPIOs are of the type where a number of lines form
> a cascaded interrupt controller chained onto
> the primary system interrupt controller (or further down the
> chain) so let's add this helper and factor the code to
> request the lines to be used as IRQs, the .to_irq() function
> and the irqdomain into the core as well.

Acked-by: Alexandre Courbot 

> Suggested-by: Thomas Gleixner 
> Signed-off-by: Linus Walleij 
> ---
>  drivers/gpio/Kconfig|   3 +
>  drivers/gpio/gpiolib.c  | 188 
> 
>  include/linux/gpio/driver.h |  29 +++
>  3 files changed, 220 insertions(+)
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index 2e461e459d88..51c782532687 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -55,6 +55,9 @@ config GPIO_ACPI
> def_bool y
> depends on ACPI
>
> +config GPIOLIB_IRQCHIP
> +   bool
> +
>  config DEBUG_GPIO
> bool "Debug GPIO calls"
> depends on DEBUG_KERNEL
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index 584d2b465f84..f76c952e08b2 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -1254,6 +1254,9 @@ fail:
>  }
>  EXPORT_SYMBOL_GPL(gpiochip_add);
>
> +/* Forward-declaration */
> +static void gpiochip_irqchip_remove(struct gpio_chip *gpiochip);
> +
>  /**
>   * gpiochip_remove() - unregister a gpio_chip
>   * @chip: the chip to unregister
> @@ -1270,6 +1273,7 @@ int gpiochip_remove(struct gpio_chip *chip)
>
> spin_lock_irqsave(_lock, flags);
>
> +   gpiochip_irqchip_remove(chip);
> gpiochip_remove_pin_ranges(chip);
> of_gpiochip_remove(chip);
>
> @@ -1339,6 +1343,190 @@ static struct gpio_chip *find_chip_by_name(const char 
> *name)
> return gpiochip_find((void *)name, gpiochip_match_name);
>  }
>
> +#ifdef CONFIG_GPIOLIB_IRQCHIP
> +
> +/*
> + * The following is irqchip helper code for gpiochips.
> + */
> +
> +/**
> + * gpiochip_add_chained_irqchip() - adds a chained irqchip to a gpiochip
> + * @gpiochip: the gpiochip to add the irqchip to
> + * @irqchip: the irqchip to add to the gpiochip
> + * @parent_irq: the irq number corresponding to the parent IRQ for this
> + * chained irqchip
> + * @parent_handler: the parent interrupt handler for the accumulated IRQ
> + * coming out of the gpiochip
> + */
> +void gpiochip_set_chained_irqchip(struct gpio_chip *gpiochip,
> + struct irq_chip *irqchip,
> + int parent_irq,
> + irq_flow_handler_t parent_handler)
> +{
> +   irq_set_chained_handler(parent_irq, parent_handler);
> +   /*
> +* The parent irqchip is already using the chip_data for this
> +* irqchip, so our callbacks simply use the handler_data.
> +*/
> +   irq_set_handler_data(parent_irq, gpiochip);
> +}
> +EXPORT_SYMBOL_GPL(gpiochip_set_chained_irqchip);
> +
> +/**
> + * gpiochip_irq_map() - maps an IRQ into a GPIO irqchip
> + * @d: the irqdomain used by this irqchip
> + * @irq: the global irq number used by this GPIO irqchip irq
> + * @hwirq: the local IRQ/GPIO line offset on this gpiochip
> + *
> + * This function will set up the mapping for a certain IRQ line on a
> + * gpiochip by assigning the gpiochip as chip data, and using the irqchip
> + * stored inside the gpiochip.
> + */
> +static int gpiochip_irq_map(struct irq_domain *d, unsigned int irq,
> +   irq_hw_number_t hwirq)
> +{
> +   struct gpio_chip *chip = d->host_data;
> +
> +   irq_set_chip_and_handler(irq, chip->irqchip, chip->irq_handler);
> +   irq_set_chip_data(irq, chip);
> +#ifdef CONFIG_ARM
> +   set_irq_flags(irq, IRQF_VALID);
> +#else
> +   irq_set_noprobe(irq);
> +#endif
> +   irq_set_irq_type(irq, chip->irq_default_type);
> +
> +   return 0;
> +}
> +
> +static const struct irq_domain_ops gpiochip_domain_ops = {
> +   .map= gpiochip_irq_map,
> +   /* Virtually all GPIO irqchips are twocell:ed */
> +   .xlate  = irq_domain_xlate_twocell,
> +};
> +
> +static int gpiochip_irq_reqres(struct irq_data *d)
> +{
> +   struct gpio_chip *chip = irq_data_get_irq_chip_data(d);
> +
> +   if (gpio_lock_as_irq(chip, d->hwirq)) {
> +   chip_err(chip,
> +   "unable to lock HW IRQ %lu for IRQ\n",
> +   d->hwirq);
> +   return -EINVAL;
> +   }
> +   return 0;
> +}
> +
> +static void gpiochip_irq_relres(struct irq_data *d)
> +{
> +   struct gpio_chip *chip = irq_data_get_irq_chip_data(d);
> +
> +   gpio_unlock_as_irq(chip, d->hwirq);
> +}
> +
> +static int gpiochip_to_irq(struct gpio_chip *chip, unsigned offset)
> 

Re: [PATCH 01/19] thermal: allow registering without .get_temp

[Alex Shi]

On 03/26/2014 10:23 AM, Zhang Rui wrote:
>> From: Eduardo Valentin 
>> > 
>> > This patch changes the thermal core driver to allow
>> > registration of thermal zones without the .get_temp callback.
>> > 
>> > The idea behind this change is to allow lazy registration
>> > of sensor callbacks.
>> > 
>> > The thermal zone will be disabled whenever the ops
>> > does not contain a .get_temp callback. The sysfs interface
>> > will be returning -EINVAL on any temperature read operation.
>> > 
>> > Cc: Zhang Rui 
>> > Cc: linux...@vger.kernel.org
>> > Cc: linux-kernel@vger.kernel.org
>> > Signed-off-by: Eduardo Valentin 
>> > (cherry picked from commit 81bd4e1cebed5efb85bd94a15342ee4d6965a416)
>> > 
>> > Signed-off-by: Alex Shi 
> why are you sending this patch series?
> all of the patches have been in upstream already.
> Plus, next time when you send a big patch set, please send with a patch
> 00/XX to give a general introduction of the whole patch set.
> 

We want to backport this patchset to linaro stable kernel which is based
on 3.10 kernel. git://git.linaro.org/kernel/linux-linaro-stable.git

It should not be spread this to community. Sorry, My fault!

-- 
Thanks
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/

[PATCH 2/2] ARM: enable fhandle in multi_v7_defconfig

[Alexandre Courbot]

CONFIG_FHANDLE is required by systemd >= 210 to spawn a serial TTY.

Signed-off-by: Alexandre Courbot 
---
 arch/arm/configs/multi_v7_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index dc02635ca473..cee30d8d253c 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -1,4 +1,5 @@
 CONFIG_SYSVIPC=y
+CONFIG_FHANDLE=y
 CONFIG_IRQ_DOMAIN_DEBUG=y
 CONFIG_NO_HZ=y
 CONFIG_HIGH_RES_TIMERS=y
-- 
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 1/2] ARM: tegra: enable fhandle in tegra_defconfig

[Alexandre Courbot]

CONFIG_FHANDLE is required by systemd >= 210 to spawn a serial TTY.

Signed-off-by: Alexandre Courbot 
---
 arch/arm/configs/tegra_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/tegra_defconfig b/arch/arm/configs/tegra_defconfig
index 131b8d6ff9d3..2926281368ab 100644
--- a/arch/arm/configs/tegra_defconfig
+++ b/arch/arm/configs/tegra_defconfig
@@ -1,4 +1,5 @@
 CONFIG_SYSVIPC=y
+CONFIG_FHANDLE=y
 CONFIG_NO_HZ=y
 CONFIG_HIGH_RES_TIMERS=y
 CONFIG_IKCONFIG=y
-- 
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 2/2] watchdog: imx2_wdt: Add big-endian support

[li.xi...@freescale.com]

> Subject: Re: [PATCH 2/2] watchdog: imx2_wdt: Add big-endian support
> 
> On 03/25/2014 02:35 AM, Xiubo Li wrote:
> > Signed-off-by: Xiubo Li 
> > ---
> 
> There is no explanation for this patch in the headline.
> 
> Ultimately there are four cases
>   CPU HW
>   little  little
This case for most IMX* and Vybird and the LS2 SoCs.



>   little   big
This case for LS1 SoC.



>   big little
Actually, this case hasn't ever occurs for this IP, but maybe in the
Feature, not now.



>   big big
This case maybe for the PowrPC SoCs.



> Current code handles big/big as well as little/little, and you are adding
> little/big to the list of supported combinations. Questions are
> 1) which combinations are possible ?
> 2) is big/little a combination which needs to be handled as well ?
> 

Yes, I originally intended to use the Regmap APIs, but it couldn't support
The 16bit registers accessing now, and also won't support the [bit  little]
case too.

So now this driver will only support the following three cases:
CPUIP
Little little
Little big
Bigbig

If there hasn't any other problems, I will resend this patches adding this
Information.



> The "big-endians" property is new and will have to be approved by the
> DT maintainers. If in fact needed, I would suggest to use "big-endian"
> as this seems to be more common.
>

Yes, There has other IP driver has been accepted by DT maintainers. So
After this I will send the DT patches to them.

 
Thanks very much,

Best Regards,
Xiubo



> Guenter
> 
> 
> >   drivers/watchdog/imx2_wdt.c | 40 +++-
> >   1 file changed, 31 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
> > index 1795922..c410981 100644
> > --- a/drivers/watchdog/imx2_wdt.c
> > +++ b/drivers/watchdog/imx2_wdt.c
> > @@ -30,6 +30,7 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >   #include 
> >   #include 
> >   #include 
> > @@ -64,9 +65,26 @@ static struct {
> > void __iomem *base;
> > unsigned timeout;
> > unsigned long status;
> > +   bool big_endian;
> > struct timer_list timer;/* Pings the watchdog when closed */
> >   } imx2_wdt;
> >
> > +static inline u16 imx2_wdt_readw(void __iomem *addr)
> > +{
> > +   if (imx2_wdt.big_endian)
> > +   return ioread16be(addr);
> > +   else
> > +   return ioread16(addr);
> > +}
> > +
> > +static inline void imx2_wdt_writew(u16 val, void __iomem *addr)
> > +{
> > +   if (imx2_wdt.big_endian)
> > +   iowrite16be(val, addr);
> > +   else
> > +   iowrite16(val, addr);
> > +}
> > +
> >   static struct miscdevice imx2_wdt_miscdev;
> >
> >   static bool nowayout = WATCHDOG_NOWAYOUT;
> > @@ -87,7 +105,7 @@ static const struct watchdog_info imx2_wdt_info = {
> >
> >   static inline void imx2_wdt_setup(void)
> >   {
> > -   u16 val = __raw_readw(imx2_wdt.base + IMX2_WDT_WCR);
> > +   u16 val = imx2_wdt_readw(imx2_wdt.base + IMX2_WDT_WCR);
> >
> > /* Suspend timer in low power mode, write once-only */
> > val |= IMX2_WDT_WCR_WDZST;
> > @@ -100,17 +118,17 @@ static inline void imx2_wdt_setup(void)
> > /* Set the watchdog's Time-Out value */
> > val |= WDOG_SEC_TO_COUNT(imx2_wdt.timeout);
> >
> > -   __raw_writew(val, imx2_wdt.base + IMX2_WDT_WCR);
> > +   imx2_wdt_writew(val, imx2_wdt.base + IMX2_WDT_WCR);
> >
> > /* enable the watchdog */
> > val |= IMX2_WDT_WCR_WDE;
> > -   __raw_writew(val, imx2_wdt.base + IMX2_WDT_WCR);
> > +   imx2_wdt_writew(val, imx2_wdt.base + IMX2_WDT_WCR);
> >   }
> >
> >   static inline void imx2_wdt_ping(void)
> >   {
> > -   __raw_writew(IMX2_WDT_SEQ1, imx2_wdt.base + IMX2_WDT_WSR);
> > -   __raw_writew(IMX2_WDT_SEQ2, imx2_wdt.base + IMX2_WDT_WSR);
> > +   imx2_wdt_writew(IMX2_WDT_SEQ1, imx2_wdt.base + IMX2_WDT_WSR);
> > +   imx2_wdt_writew(IMX2_WDT_SEQ2, imx2_wdt.base + IMX2_WDT_WSR);
> >   }
> >
> >   static void imx2_wdt_timer_ping(unsigned long arg)
> > @@ -143,12 +161,12 @@ static void imx2_wdt_stop(void)
> >
> >   static void imx2_wdt_set_timeout(int new_timeout)
> >   {
> > -   u16 val = __raw_readw(imx2_wdt.base + IMX2_WDT_WCR);
> > +   u16 val = imx2_wdt_readw(imx2_wdt.base + IMX2_WDT_WCR);
> >
> > /* set the new timeout value in the WSR */
> > val &= ~IMX2_WDT_WCR_WT;
> > val |= WDOG_SEC_TO_COUNT(new_timeout);
> > -   __raw_writew(val, imx2_wdt.base + IMX2_WDT_WCR);
> > +   imx2_wdt_writew(val, imx2_wdt.base + IMX2_WDT_WCR);
> >   }
> >
> >   static int imx2_wdt_open(struct inode *inode, struct file *file)
> > @@ -192,7 +210,7 @@ static long imx2_wdt_ioctl(struct file *file, unsigned
> int cmd,
> > return put_user(0, p);
> >
> > case WDIOC_GETBOOTSTATUS:
> > -   val = __raw_readw(imx2_wdt.base + IMX2_WDT_WRSR);
> > +   val = imx2_wdt_readw(imx2_wdt.base + IMX2_WDT_WRSR);
> > new_value = val & IMX2_WDT_WRSR_TOUT ? WDIOF_CARDRESET : 0;
> >  

Re: [PATCH 01/19] thermal: allow registering without .get_temp

[Zhang Rui]

On Tue, 2014-03-25 at 18:49 +0800, Alex Shi wrote:
> From: Eduardo Valentin 
> 
> This patch changes the thermal core driver to allow
> registration of thermal zones without the .get_temp callback.
> 
> The idea behind this change is to allow lazy registration
> of sensor callbacks.
> 
> The thermal zone will be disabled whenever the ops
> does not contain a .get_temp callback. The sysfs interface
> will be returning -EINVAL on any temperature read operation.
> 
> Cc: Zhang Rui 
> Cc: linux...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin 
> (cherry picked from commit 81bd4e1cebed5efb85bd94a15342ee4d6965a416)
> 
> Signed-off-by: Alex Shi 

why are you sending this patch series?
all of the patches have been in upstream already.
Plus, next time when you send a big patch set, please send with a patch
00/XX to give a general introduction of the whole patch set.

thanks,
rui
> ---
>  drivers/thermal/thermal_core.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/thermal/thermal_core.c b/drivers/thermal/thermal_core.c
> index d755440..818cd78 100644
> --- a/drivers/thermal/thermal_core.c
> +++ b/drivers/thermal/thermal_core.c
> @@ -388,7 +388,7 @@ int thermal_zone_get_temp(struct thermal_zone_device *tz, 
> unsigned long *temp)
>   enum thermal_trip_type type;
>  #endif
>  
> - if (!tz || IS_ERR(tz))
> + if (!tz || IS_ERR(tz) || !tz->ops->get_temp)
>   goto exit;
>  
>   mutex_lock(>lock);
> @@ -441,6 +441,9 @@ void thermal_zone_device_update(struct 
> thermal_zone_device *tz)
>  {
>   int count;
>  
> + if (!tz->ops->get_temp)
> + return;
> +
>   update_temperature(tz);
>  
>   for (count = 0; count < tz->trips; count++)
> @@ -1621,7 +1624,7 @@ struct thermal_zone_device 
> *thermal_zone_device_register(const char *type,
>   if (trips > THERMAL_MAX_TRIPS || trips < 0 || mask >> trips)
>   return ERR_PTR(-EINVAL);
>  
> - if (!ops || !ops->get_temp)
> + if (!ops)
>   return ERR_PTR(-EINVAL);
>  
>   if (trips > 0 && !ops->get_trip_type)
> @@ -1723,6 +1726,9 @@ struct thermal_zone_device 
> *thermal_zone_device_register(const char *type,
>  
>   INIT_DELAYED_WORK(&(tz->poll_queue), thermal_zone_device_check);
>  
> + if (!tz->ops->get_temp)
> + thermal_zone_device_set_polling(tz, 0);
> +
>   thermal_zone_device_update(tz);
>  
>   if (!result)


--
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] arm64: Fix memory layout typo

[Neil Zhang]

Signed-off-by: Neil Zhang 
---
 Documentation/arm64/memory.txt |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/arm64/memory.txt b/Documentation/arm64/memory.txt
index 5e054bf..c2765e2 100644
--- a/Documentation/arm64/memory.txt
+++ b/Documentation/arm64/memory.txt
@@ -39,7 +39,7 @@ ffbffbc0  ffbffbdf   2MB  
earlyprintk device
 
 ffbffbe0   ffbffbe0  64KB  PCI I/O space
 
-ffbffbe1   ffbc  ~2MB  [guard]
+ffbffbe1   ffbffbff  ~2MB  [guard]
 
 ffbffc00   ffbf  64MB  modules
 
-- 
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/

Re: [PATCH 2/2] watchdog: imx2_wdt: Add big-endian support

[Guenter Roeck]

On 03/25/2014 02:35 AM, Xiubo Li wrote:

Signed-off-by: Xiubo Li 
---


There is no explanation for this patch in the headline.

Ultimately there are four cases
CPU HW
little  little
little  big
big little
big big
Current code handles big/big as well as little/little, and you are adding
little/big to the list of supported combinations. Questions are
1) which combinations are possible ?
2) is big/little a combination which needs to be handled as well ?

The "big-endians" property is new and will have to be approved by the
DT maintainers. If in fact needed, I would suggest to use "big-endian"
as this seems to be more common.

Guenter



  drivers/watchdog/imx2_wdt.c | 40 +++-
  1 file changed, 31 insertions(+), 9 deletions(-)

diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
index 1795922..c410981 100644
--- a/drivers/watchdog/imx2_wdt.c
+++ b/drivers/watchdog/imx2_wdt.c
@@ -30,6 +30,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 
@@ -64,9 +65,26 @@ static struct {
void __iomem *base;
unsigned timeout;
unsigned long status;
+   bool big_endian;
struct timer_list timer;/* Pings the watchdog when closed */
  } imx2_wdt;

+static inline u16 imx2_wdt_readw(void __iomem *addr)
+{
+   if (imx2_wdt.big_endian)
+   return ioread16be(addr);
+   else
+   return ioread16(addr);
+}
+
+static inline void imx2_wdt_writew(u16 val, void __iomem *addr)
+{
+   if (imx2_wdt.big_endian)
+   iowrite16be(val, addr);
+   else
+   iowrite16(val, addr);
+}
+
  static struct miscdevice imx2_wdt_miscdev;

  static bool nowayout = WATCHDOG_NOWAYOUT;
@@ -87,7 +105,7 @@ static const struct watchdog_info imx2_wdt_info = {

  static inline void imx2_wdt_setup(void)
  {
-   u16 val = __raw_readw(imx2_wdt.base + IMX2_WDT_WCR);
+   u16 val = imx2_wdt_readw(imx2_wdt.base + IMX2_WDT_WCR);

/* Suspend timer in low power mode, write once-only */
val |= IMX2_WDT_WCR_WDZST;
@@ -100,17 +118,17 @@ static inline void imx2_wdt_setup(void)
/* Set the watchdog's Time-Out value */
val |= WDOG_SEC_TO_COUNT(imx2_wdt.timeout);

-   __raw_writew(val, imx2_wdt.base + IMX2_WDT_WCR);
+   imx2_wdt_writew(val, imx2_wdt.base + IMX2_WDT_WCR);

/* enable the watchdog */
val |= IMX2_WDT_WCR_WDE;
-   __raw_writew(val, imx2_wdt.base + IMX2_WDT_WCR);
+   imx2_wdt_writew(val, imx2_wdt.base + IMX2_WDT_WCR);
  }

  static inline void imx2_wdt_ping(void)
  {
-   __raw_writew(IMX2_WDT_SEQ1, imx2_wdt.base + IMX2_WDT_WSR);
-   __raw_writew(IMX2_WDT_SEQ2, imx2_wdt.base + IMX2_WDT_WSR);
+   imx2_wdt_writew(IMX2_WDT_SEQ1, imx2_wdt.base + IMX2_WDT_WSR);
+   imx2_wdt_writew(IMX2_WDT_SEQ2, imx2_wdt.base + IMX2_WDT_WSR);
  }

  static void imx2_wdt_timer_ping(unsigned long arg)
@@ -143,12 +161,12 @@ static void imx2_wdt_stop(void)

  static void imx2_wdt_set_timeout(int new_timeout)
  {
-   u16 val = __raw_readw(imx2_wdt.base + IMX2_WDT_WCR);
+   u16 val = imx2_wdt_readw(imx2_wdt.base + IMX2_WDT_WCR);

/* set the new timeout value in the WSR */
val &= ~IMX2_WDT_WCR_WT;
val |= WDOG_SEC_TO_COUNT(new_timeout);
-   __raw_writew(val, imx2_wdt.base + IMX2_WDT_WCR);
+   imx2_wdt_writew(val, imx2_wdt.base + IMX2_WDT_WCR);
  }

  static int imx2_wdt_open(struct inode *inode, struct file *file)
@@ -192,7 +210,7 @@ static long imx2_wdt_ioctl(struct file *file, unsigned int 
cmd,
return put_user(0, p);

case WDIOC_GETBOOTSTATUS:
-   val = __raw_readw(imx2_wdt.base + IMX2_WDT_WRSR);
+   val = imx2_wdt_readw(imx2_wdt.base + IMX2_WDT_WRSR);
new_value = val & IMX2_WDT_WRSR_TOUT ? WDIOF_CARDRESET : 0;
return put_user(new_value, p);

@@ -257,8 +275,12 @@ static struct miscdevice imx2_wdt_miscdev = {

  static int __init imx2_wdt_probe(struct platform_device *pdev)
  {
-   int ret;
+   struct device_node *np = pdev->dev.of_node;
struct resource *res;
+   int ret;
+
+   if (np)
+   imx2_wdt.big_endian = of_property_read_bool(np, "big-endians");

res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
imx2_wdt.base = devm_ioremap_resource(>dev, res);



--
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 v2 8/9] net: filter: rework/optimize internal BPF interpreter's instruction set

[Alexei Starovoitov]

On Tue, Mar 25, 2014 at 5:46 PM, David Miller  wrote:
> From: "H. Peter Anvin" 
> Date: Tue, 25 Mar 2014 17:24:27 -0700
>
>> If you allow loops, it greatly increases the expressibility of the
>> language, but we would really need another control to limit CPU usage.
>
> We don't want super expressibility.
>
> We want an extremely simple, trivial to validate, filtering language.

Filtering language is unchanged. It's still the same classic BPF
and in this patch set all jumps are forward only.
We didn't touch sk_chk_filter(), so it's allowing forward only jumps.
Classic bpf and ebpf instruction sets can accommodate both.
It's bpf verifier (sk_chk_filter) that allows one or the other.

So I think we can debate backward jumps later when they actually
will be up for review.

I think we can allow backward jumps in the future, since it helps
llvm/gcc to generate more efficient code, reduce code duplication, etc
Extended bpf verifier is still simple enough and it detects loops
by doing DAG check.
See check_cfg() that was part of V1 series.
The DAG check is from the wikipedia. It's looking for a back-edge.
If back-edge is present, it means loop is possible, so whole ebpf
program is thrown out.
I think even classic BPF requires DAG check,
since today sk_chk_filter() allows unreachable instructions,
so attacker can write a bpf program that jumps over junk instructions.
I cannot imagine how this little hole can be exploited, but I think
it's safer to close it.
So we're planning to send patches to close this 10 year old
hole in the future series.

After extended verifier is reviewed and it still feels wrong, we can
make it more restrictive and disallow backward jumps, but that
will complicate llvm/gcc.

Thanks
Alexei
--
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: comedi: s626: use comedi_timeout() on remaining loops

[Chase Southwood]

Ian,

>On Tuesday, March 25, 2014 7:13 AM, Ian Abbott  wrote:
>>On 2014-03-25 05:09, Chase Southwood wrote:
>>There were just a handful of more while loops in this file that need timeouts,
>>and this patch takes care of them, using comedi_timeout().  A couple of new
>>callbacks are introduced, but there was one case where the appropriate 
>>callback
>>function was already defined; in this case I have just used that.
>>
>>Signed-off-by: Chase Southwood 
>
>I think it can be simplified a bit as described below.


[snip]

Thank you for all of this great feedback, I'll get this fixed up as quick as I 
can.

Thanks,
Chase
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] mmc: rtsx: add new cmd type handle and modify errorhandle

[micky]

Hi Ulf,
On 03/25/2014 06:44 PM, Ulf Hansson wrote:

On 25 March 2014 10:47,   wrote:

From: Micky Ching 

Add new command type(R1 without CRC) handle, without this
patch mmc card initialize will be failed.

Using a more careful handle in request timeout, this would
improve error recover capability. Debug info is printed
using non DMA mode, this would help print more accurately
for DMA command failed. Smatch warning was removed.

Hi Micky,

Seems like this patchset has been around for some time, sorry for the delay.

I don't have any objections to it getting merged, but you need to run
checkpatch of your patches. Patch2 has a warning you should fix.

Patch2 is based on 
see: https://lkml.org/lkml/2014/2/17/270
checkpatch.pl seems ok, is there any thing I need to check?

Best Regards.
micky.

Kind regards
Ulf Hansson



Micky Ching (2):
   mmc: rtsx: add R1-no-CRC mmc command type handle
   mmc: rtsx: modify error handle and remove smatch warnings

  drivers/mmc/host/rtsx_pci_sdmmc.c |  121 -
  1 file changed, 67 insertions(+), 54 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/

Re: [PATCH] drivers/net: Use RCU_INIT_POINTER(x, NULL) in tun.c

[David Miller]

From: Monam Agarwal 
Date: Mon, 24 Mar 2014 00:02:32 +0530

> This patch replaces rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, NULL)
> 
> The rcu_assign_pointer() ensures that the initialization of a structure   
> is carried out before storing a pointer to that structure. 
> And in the case of the NULL pointer, there is no structure to initialize. 
> So, rcu_assign_pointer(p, NULL) can be safely converted to 
> RCU_INIT_POINTER(p, NULL)
> 
> Signed-off-by: Monam Agarwal 

Applied.
--
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/bridge: Use RCU_INIT_POINTER(x, NULL) in br_vlan.c

[David Miller]

From: Monam Agarwal 
Date: Mon, 24 Mar 2014 00:41:13 +0530

> This patch replaces rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, NULL)
> 
> The rcu_assign_pointer() ensures that the initialization of a structure   
> is carried out before storing a pointer to that structure. 
> And in the case of the NULL pointer, there is no structure to initialize. 
> So, rcu_assign_pointer(p, NULL) can be safely converted to 
> RCU_INIT_POINTER(p, NULL)
> 
> Signed-off-by: Monam Agarwal 

Applied.
--
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/core: Use RCU_INIT_POINTER(x, NULL) in netpoll.c

[David Miller]

From: Monam Agarwal 
Date: Mon, 24 Mar 2014 00:42:46 +0530

> This patch replaces rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, NULL)
> 
> The rcu_assign_pointer() ensures that the initialization of a structure   
> is carried out before storing a pointer to that structure. 
> And in the case of the NULL pointer, there is no structure to initialize. 
> So, rcu_assign_pointer(p, NULL) can be safely converted to 
> RCU_INIT_POINTER(p, NULL)
> 
> Signed-off-by: Monam Agarwal 

Applied.
--
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] drivers/net: Use RCU_INIT_POINTER(x, NULL) in bonding/bond_options.c

[David Miller]

From: Monam Agarwal 
Date: Mon, 24 Mar 2014 00:00:17 +0530

> This patch replaces rcu_assign_pointer(x, NULL) with RCU_INIT_POINTER(x, NULL)
> 
> The rcu_assign_pointer() ensures that the initialization of a structure   
> is carried out before storing a pointer to that structure. 
> And in the case of the NULL pointer, there is no structure to initialize. 
> So, rcu_assign_pointer(p, NULL) can be safely converted to 
> RCU_INIT_POINTER(p, NULL)
> 
> Signed-off-by: Monam Agarwal 

Applied.
--
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 1/1] fs/reiserfs/journal.c: Remove obsolete __GFP_NOFAIL

[David Rientjes]

On Sat, 22 Mar 2014, Joe Perches wrote:

> How about just changing this message to something like:
> 
>   WARN("__GFP_NOFAIL",
>"Use of __GFP_NOFAIL may cause the OOM handler to 
> kill a random process\n" . $herecurr);

Because it doesn't, the GFP_NOFS allocation in question already cannot 
invoke the oom killer.
--
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 1/1] fs/reiserfs/journal.c: Remove obsolete __GFP_NOFAIL

[David Rientjes]

On Sat, 22 Mar 2014, Dave Jones wrote:

> On Sat, Mar 22, 2014 at 10:55:24AM -0700, Andrew Morton wrote:
>  > On Sat, 22 Mar 2014 13:32:07 -0400 ty...@mit.edu wrote:
>  > 
>  > > On Sat, Mar 22, 2014 at 01:26:06PM -0400, ty...@mit.edu wrote:
>  > > > > Well.  Converting an existing retry-for-ever caller to GFP_NOFAIL is
>  > > > > good.  Adding new retry-for-ever code is not good.
>  > > 
>  > > Oh, and BTW --- now that checkpatch.pl now flags an warning whenever
>  > > GFP_NOFAIL is used
>  > 
>  > I don't know what the basis for this NOFAIL-is-going-away theory could
>  > have been.  What's the point in taking a centrally implemented piece of
>  > logic and splattering its implementation out to tens of different
>  > callsites?
> 
> I wonder if some of that thinking came from this..
> 
> commit dab48dab37d2770824420d1e01730a107fade1aa
> Author: Andrew Morton 
> Date:   Tue Jun 16 15:32:37 2009 -0700
> 
> page-allocator: warn if __GFP_NOFAIL is used for a large allocation
> 
> __GFP_NOFAIL is a bad fiction.  Allocations _can_ fail, and callers should
> detect and suitably handle this (and not by lamely moving the infinite
> loop up to the caller level either).
> 

It came from me pointing out the fact that __GFP_NOFAIL requires 
__GFP_WAIT to actually never fail in the page allocator's implementation.  
I wanted to fix that, Andrew said nobody is currently doing 
GFP_NOWAIT | __GFP_NOFAIL or GFP_ATOMIC | __GFP_NOFAIL so let's warn 
against new callers being added and hopefully eventually get rid of it.  
In those cases, we also don't invoke the oom killer because we don't have 
__GFP_FS so we livelock.

The point is not to add new callers and new code should handle NULL 
correctly, not that we should run around changing current users to just do 
infinite retries.  Checkpatch should have nothing to do with that.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 07/16] atm: firestream: Use del_timer_sync() in teardown path

[David Miller]

From: Thomas Gleixner 
Date: Sun, 23 Mar 2014 15:09:28 -

> The device is about to vanish. So we need to make sure that the timer
> is completely stopped and the callback is not running on another CPU.
> 
> Signed-off-by: Thomas Gleixner 

Applied.
--
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 08/16] atm: idt77105: Use del_timer_sync() in exit path

[David Miller]

From: Thomas Gleixner 
Date: Sun, 23 Mar 2014 15:09:28 -

> The module is about to go away. Make sure everything is stopped safely
> before we pull the plug.
> 
> Signed-off-by: Thomas Gleixner 

Applied.
--
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: [Regression, bisected 9e30cc] "sysfs, kernfs: no need to kern_mount() sysfs from sysfs_init()" prevents system from booting correctly

[Alexandre Demers]

So, I tried RC8 and I'm still getting the error. It start too fast to 
be able to read whatever it is saying, but here is what I can read:

...
cp: error writing /run/initramfs/new_root/...
cp: failed to extend ...
... (and so on)

It goes on like that for a long time.

Alexandre Demers

On Mon 17 Mar 2014 10:08:40 PM EDT, Alexandre Demers wrote:

By the way, I tried to get the error message, but my display had gone
in standby mode before it completed and it wouldn't wake up. I'll have
to test with an earlier 3.14 kernel (rc1 or rc2), when it was
answering to my wake up signal. Even though my display doesn't wake up
with rc6, it is still running since I can see some activities on my
disk from time to time.

I'll be back with more info ASAP.

Alexandre Demers

On Mon 17 Mar 2014 04:13:46 PM EDT, Tejun Heo wrote:

Hello,

On Fri, Mar 14, 2014 at 11:48:10AM -0400, Alexandre Demers wrote:

Since it takes a while before the system begins to display errors,
I'll have to test it and report it later today when I'll get back from
work.


Any update?


Now, about the userland part, this seems a broad question... I'm using
Arch Linux 64bit (updated mostly on a daily basis). But I suspect you
are expecting a narrower information. Is there anything in particular
you want to know?


I was just wondering whether you were running something really exotic.
Doesn't seem that way.  Weird that other people aren't hitting this
issue.  Hmm...

Thanks.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] bonding: Inactive slaves should keep inactive flag's value to 1 in tlb and alb mode.

[Ding Tianhong]

On 2014/3/25 16:36, zheng.li wrote:
> 于 2014年03月25日 11:42, Ding Tianhong 写道:
>> On 2014/3/25 11:00, Zheng Li wrote:
>>> In bond mode tlb and alb, inactive slaves should keep inactive flag to
>>> 1 to refuse to receive broadcast packets. Now, active slave send broadcast 
>>> packets
>>> (for example ARP requests) which will arrive inactive slaves on same host 
>>> from switch,
>>> but inactive slave's inactive flag is zero that cause bridge receive the 
>>> broadcast
>>> packets to produce a wrong entry in forward table. Typical situation is 
>>> domu send some
>>> ARP request which go out from dom0 bond's active slave, then the ARP 
>>> broadcast request
>>> packets go back to inactive slave from switch, because the inactive slave's 
>>> inactive
>>> flag is zero, kernel will receive the packets and pass them to bridge, that 
>>> cause dom0's
>>> bridge map domu's MAC address to port of bond, bridge should map domu's MAC 
>>> to port of vif.
>>>
>>> Signed-off-by: Zheng Li 
>>> ---
>>>  drivers/net/bonding/bond_main.c |2 +-
>>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/net/bonding/bond_main.c 
>>> b/drivers/net/bonding/bond_main.c
>>> index e5628fc..8761df6 100644
>>> --- a/drivers/net/bonding/bond_main.c
>>> +++ b/drivers/net/bonding/bond_main.c
>>> @@ -3062,7 +3062,7 @@ static int bond_open(struct net_device *bond_dev)
>>> && (slave != bond->curr_active_slave)) {
>>> bond_set_slave_inactive_flags(slave,
>>>   
>>> BOND_SLAVE_NOTIFY_NOW);
>>> -   } else {
>>> +   } else if (!bond_is_lb(bond)) {
>>> bond_set_slave_active_flags(slave,
>>> 
>>> BOND_SLAVE_NOTIFY_NOW);
>>> }
>>>
>> I think you did not fix the problem completely, the state monitor will 
>> change the status for the slaves
>> and the inactive slave still could receive the broadcast.
> 
> Had tested, it can fix the issue, verified by our QA.
> Default set slave of bond as inactive when add a slave to bond, when
> link UP, just set one slave as current active slave and clear its
> inactive flag, the inactive slave's inactive flag will keep the value of 1.
> 
> 
Ok, I found that in the mii monitor, it will only change the backup state, no 
problem,
it looks good to me.

Ding

>>
>> Regards
>> Ding
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>
> 
> 
> 
> .
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: machine_power_off should not return

[Russell King - ARM Linux]

On Tue, Mar 25, 2014 at 07:45:55PM -0300, Ezequiel Garcia wrote:
> Let's Cc: LAKML, and To: Russell.
> 
> Russell, any comments on this?
> 
> Without this patch we got the heartbeat's reboot_notifier called twice while
> testing the recent hibernation patches, which was unexpected and produced a
> kernel panic: https://lkml.org/lkml/2014/3/19/363

I don't see why we should make this change.  kernel/reboot.c handles
this function returning, so other places should do too.

Even on x86, this function can return:

void machine_power_off(void)
{
machine_ops.power_off();
}

.power_off = native_machine_power_off,

static void native_machine_power_off(void)
{
if (pm_power_off) {
if (!reboot_force)
machine_shutdown();
pm_power_off();
}
/* A fallback in case there is no PM info available */
tboot_shutdown(TB_SHUTDOWN_HALT);
}

void tboot_shutdown(u32 shutdown_type)
{
void (*shutdown)(void);

if (!tboot_enabled())
return;

Therefore, I'd say... it's a bug in the hibernation code - or we probably
have many buggy architectures.  I'd suggest fixing the hibernation code
rather than stuffing some workaround like an endless loop into every
architecture.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next,v4] hyperv: Add support for virtual Receive Side Scaling (vRSS)

[David Miller]

From: David Miller 
Date: Tue, 25 Mar 2014 20:43:43 -0400 (EDT)

> From: Haiyang Zhang 
> Date: Tue, 25 Mar 2014 20:37:43 +
> 
>> Do we know when the dependency (commit: 8a7206a89f) will be merged
>> into net-next tree?
> 
> You're really not very patient, to say the least.
> 
> It's done now and I'm working to integrate your patch.
> 
> That patch has been in under review state in patchwork, which means
> that I will get to it at some point, so you don't need to worry about
> it any more than any other patch you might submit.
> 
> The whole reason patchwork exists is so that people don't have to
> ask.

And actually, this dependency "8a7206a89f" commit doesn't exist
in the 'net' tree at all.  I just merged Linus's tree into 'net'
and it doesn't exist there either.

So this patch still doesn't compile.

I'm tossing it from patchwork until you sort this out.
--
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 v2 8/9] net: filter: rework/optimize internal BPF interpreter's instruction set

[David Miller]

From: "H. Peter Anvin" 
Date: Tue, 25 Mar 2014 17:24:27 -0700

> If you allow loops, it greatly increases the expressibility of the
> language, but we would really need another control to limit CPU usage.

We don't want super expressibility.

We want an extremely simple, trivial to validate, filtering language.
--
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] Add VID/PID for HID-type Multi-Touch Module of AFO CO., LTD.

[YongHwan Ki]

Sorry, I woud like to add the AFO defines in the Linux Kernel.
No afo defines exists in the current kernel tree.
I correctly changed the log for adding the afo defines.

Kernel Version : linux-3.14.rc7
Signed-off-by: Yonghwan Ki 

diff -uprN -X Documentation/dontdiff ./drivers/hid/hid-core.c 
../linux-3.14-rc7m/drivers/hid/hid-core.c
--- ./drivers/hid/hid-core.c2014-03-17 10:51:24.0 +0900
+++ ../linux-3.14-rc7m/drivers/hid/hid-core.c   2014-03-21 17:41:51.846939444 
+0900
@@ -1881,6 +1881,8 @@ static const struct hid_device_id hid_ha
{ HID_USB_DEVICE(USB_VENDOR_ID_ZEROPLUS, 0x0005) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ZEROPLUS, 0x0030) },
{ HID_USB_DEVICE(USB_VENDOR_ID_ZYDACRON, 
USB_DEVICE_ID_ZYDACRON_REMOTE_CONTROL) },
+   { HID_USB_DEVICE(USB_VENDOR_ID_AFO, USB_DEVICE_ID_AFO_TCM) },
+   { HID_USB_DEVICE(USB_VENDOR_ID_AFO, USB_DEVICE_ID_AFO_THM) },
 
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_PRESENTER_8K_BT) },
{ HID_BLUETOOTH_DEVICE(USB_VENDOR_ID_NINTENDO, 
USB_DEVICE_ID_NINTENDO_WIIMOTE) },
diff -uprN -X Documentation/dontdiff ./drivers/hid/hid-ids.h 
../linux-3.14-rc7m/drivers/hid/hid-ids.h
--- ./drivers/hid/hid-ids.h 2014-03-17 10:51:24.0 +0900
+++ ../linux-3.14-rc7m/drivers/hid/hid-ids.h2014-03-21 17:30:34.478959555 
+0900
@@ -960,5 +960,9 @@
 #define USB_VENDOR_ID_PRIMAX   0x0461
 #define USB_DEVICE_ID_PRIMAX_KEYBOARD  0x4e05
 
+#define USB_VENDOR_ID_AFO  0x2576
+#define USB_DEVICE_ID_AFO_TCM  0x0003
+#define USB_DEVICE_ID_AFO_BL   0x0005
+#define USB_DEVICE_ID_AFO_THM  0x0011
 
 #endif
diff -uprN -X Documentation/dontdiff ./drivers/hid/hid-multitouch.c 
../linux-3.14-rc7m/drivers/hid/hid-multitouch.c
--- ./drivers/hid/hid-multitouch.c  2014-03-17 10:51:24.0 +0900
+++ ../linux-3.14-rc7m/drivers/hid/hid-multitouch.c 2014-03-21 
17:45:25.946933088 +0900
@@ -1395,6 +1395,15 @@ static const struct hid_device_id mt_dev
{  .driver_data = MT_CLS_WIN_8,
HID_DEVICE(HID_BUS_ANY, HID_GROUP_MULTITOUCH_WIN_8,
HID_ANY_ID, HID_ANY_ID) },
+
+   /* AFO MultiTouch device */
+   {  .driver_data = MT_CLS_SERIAL,
+   HID_USB_DEVICE(USB_VENDOR_ID_AFO,
+   USB_DEVICE_ID_AFO_TCM) },
+   {  .driver_data = MT_CLS_SERIAL,
+   HID_USB_DEVICE(USB_VENDOR_ID_AFO,
+   USB_DEVICE_ID_AFO_THM) },
+
{ }
 };
 MODULE_DEVICE_TABLE(hid, mt_devices);
Binary files ./kernel/x509_certificate_list and 
../linux-3.14-rc7m/kernel/x509_certificate_list differ
diff -uprN -X Documentation/dontdiff ./lib/oid_registry_data.c 
../linux-3.14-rc7m/lib/oid_registry_data.c
--- ./lib/oid_registry_data.c   2014-03-21 18:45:37.598825862 +0900
+++ ../linux-3.14-rc7m/lib/oid_registry_data.c  2014-03-24 21:43:59.826812763 
+0900
@@ -1,5 +1,5 @@
 /*
- * Automatically generated by /usr/src/linux-3.14-rc7/lib/build_OID_registry.  
Do not edit
+ * Automatically generated by /usr/src/linux-3.14-rc7m/lib/build_OID_registry. 
 Do not edit
  */
 
 static const unsigned short oid_index[OID__NR + 1] = {
diff -uprN -X Documentation/dontdiff ./signing_key.priv 
../linux-3.14-rc7m/signing_key.priv
--- ./signing_key.priv  2014-03-21 17:24:11.874970914 +0900
+++ ../linux-3.14-rc7m/signing_key.priv 2014-03-24 20:22:01.946958769 +0900
@@ -1,52 +1,52 @@
 -BEGIN PRIVATE KEY-
-MIIJQwIBADANBgkqhkiG9w0BAQEFAASCCS0wggkpAgEAAoICAQDHSyVGQWUsS2TS
-woXvK+PRaT+MiYP8QyR7Ak89fo/9x/nFBcfqmA+uXZ3Akje1bZ0JRzzIp//TdI6T
-hbLLW5Rl/eRq1097rWvRclCtF0WkSMz8FG2N7eyETbVinQDUacFj1BR5H+PLbx9X
-D5ZVCOdHy8ad0MeuNz6Y4RwNLpRBNnYFd87N+MC7yi5702mAlMnt7cbbn+hHwqoK
-SgSANepLsLdPdNIWdvCxlqySGe1ElbHBadzdLf9fFk9p8H4TiTaEd3z0wK9dQebI
-a79KWMXnkxUCnCurM2rNdVOelx9czh43uDNXLPbp0JelDNKZY16dQ3RFlvrVcOpa
-RDGY+AnpaiBNBJ7cT6rgKkKiupXMQzgHRhZ/CW1cM8NmCzseG/K5ovHNtxnNMkkO
-8VUaXnPNNm1rgdQRICCzsd7zfng0dEEgbFY/6sJ22m8AbJRWXG0Jvjlw8mBp3ZjZ
-pfI1ZkJTIPFJVxO9R3CY9i+tQ6hlH+atUlxLRJO24xhz5x7LGFpexemHMb5D9iT+
-SvlaOapLo4vA1w2xAeaa1Rz2W5AZyexTJSW/zQDol/6CgB/zg8GIi3fbrI79J2IU
-43FZId1HVuQCf9MIRHogsZcPhk08ByR3CmRlxr2Ib/XYCXzqNPIg2GIqoZyLyLw9
-PbsiGgIFxyB+6ogwG6f4E2Ph3dS2nwIDAQABAoICAGYQ2jos67/PrQczkJx5AegR
-2vYCx5G+YUSOXj7EPsJeVFDPMR+4WO+YCl7Bg75rMO27iinJwH9vRkXPR05WzJ2f
-dggx1QcmPf26ag77yDLnBfRkEeeKXoMzuR2UAwTGVMDnsMSHzIY3lvljhj5unORs
-PIA+mMVkja6GO3OU02DCn5cVUNiz+SEz3rKUB4hOq0wrZpi8QJ3f2G4EkmGHO0Mg
-cgFDdwUCTSrmW+NHW/iwIaVIrlCoag0sw+chv7AJqd4Vw+0lcap1QdiLNiDBbjm3
-Xh9EFClN3/jxia3C/9DrzxYCRGj1Ik+FAOUKuCDOf3pTPY0WUchWV+961VveTFRS
-ARjpfHZF2v2quID+EKi3SQCmBUn1g0sNznPIttfUQYMqiTu0v36TEfFxyIWRXGK0
-tcuc4ipXHfggp8jrhq62NjtSBOEPHptFnyP/etLv+AiYetxDWLM1S/M63JQHYO9d
-dL7g/4QemeLhItOil1YsJLai5EfY/5bh4iAJZvteUDqPoovkV87xasB8+rtB2S7y
-G6izBrebXzNppSgQdu29a9wTEMmoFE+AcqIU2kvOAWts2IQCwLUG08Yh1ivqZ7zf
-WcCmxP35e1PDpm4lVXf8r/COzft9KEts7aPHeg4emVdgwzlZyl++cb2n1W60AzTv
-57PmmrzqyAZy9yTO1kThAoIBAQD5dLMb7Lp4/4Udappl8zQGlLizWgXQbJZSxP22

Re: [PATCH net-next,v4] hyperv: Add support for virtual Receive Side Scaling (vRSS)

[David Miller]

From: Haiyang Zhang 
Date: Tue, 25 Mar 2014 20:37:43 +

> Do we know when the dependency (commit: 8a7206a89f) will be merged
> into net-next tree?

You're really not very patient, to say the least.

It's done now and I'm working to integrate your patch.

That patch has been in under review state in patchwork, which means
that I will get to it at some point, so you don't need to worry about
it any more than any other patch you might submit.

The whole reason patchwork exists is so that people don't have to
ask.
--
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 00/14] CPU idle for Armada XP

[Jason Cooper]

Gregory,

On Tue, Mar 25, 2014 at 11:48:11PM +0100, Gregory CLEMENT wrote:
...
> The first patch should go through ARM subsystem and should be taken by
> Russell King. I made few change on it following Lorenzo advice and
> now it will reuse the cpu v7 suspend and resume function and just do
> specific operation before calling them.
> 
> The 13th patch 'cpuidle: mvebu: Add initial cpu idle support for
> Armada 370/XP SoC' is the only one who should go to the cpuidle
> subsystem. But of course I would like that Daniel Lezcano or Rafael
> J. Wysocki have a look on the whole series and especially patches 10,
> 12 and 14.

Ok, I'm tired.  :)  Help me out here.  Patches 1 and 13 are depended on
by the other patches and vice-versa, right?  In that case, I'm thinking
it's best to seek Acks from the other maintainers and keep the whole
branch together.  Please tell me if I'm wrong.

thx,

Jason.
--
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: gpf in simple_setattr

[Linus Torvalds]

On Tue, Mar 25, 2014 at 2:12 PM, Jan Kara  wrote:
>
>   Can you try whether the following patch fixes the issue for you?

Good catch, Honza.

I hate how fragile that code ends up being and would love to see that
"anon_inode_inode" allocation and assignment just once in
anon_inode_init(), but considering that it wants the superblock
pointer, I suspect it's not cleanly doable. Oh well. Your patch looks
like it should make the issue moot, I just dread this happening again
due to the layout of the code.

Will apply the patch,

 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 v5 08/14] ARM: dts: mvebu: Introduce a new compatible for the PMSU node

[Jason Cooper]

On Tue, Mar 25, 2014 at 11:48:19PM +0100, Gregory CLEMENT wrote:
> The initial binding for PMSU were wrong. It didn't take into account
> all the registers from the PMSU and in the other hand refereed to
> registers which are not part of PMSU. This commit introduces a new
> compatible for the PMSU node and annotates the previous one as
> obsolete. However we still continue to support it during a few
> releases.
> 
> Cc: devicet...@vger.kernel.org
> Signed-off-by: Gregory CLEMENT 
> ---
>  .../devicetree/bindings/arm/armada-370-xp-pmsu.txt | 14 
> ++
>  arch/arm/boot/dts/armada-xp.dtsi   | 11 ---
>  2 files changed, 14 insertions(+), 11 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt 
> b/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt
> index 926b4d6aae7e..976188770079 100644
> --- a/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt
> +++ b/Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt
> @@ -4,17 +4,15 @@ Available on Marvell SOCs: Armada 370 and Armada XP
>  
>  Required properties:
>  
> -- compatible: "marvell,armada-370-xp-pmsu"
> +- compatible: should be "marvell,armada-370-pmsu", whereas
> +  "marvell,armada-370-xp-pmsu" is deprecated and will be removed

:)  ignore my comment on the previous patch.

> -- reg: Should contain PMSU registers location and length. First pair
> -  for the per-CPU SW Reset Control registers, second pair for the
> -  Power Management Service Unit.
> +- reg: Should contain PMSU registers location and length.
>  
>  Example:
>  
> -armada-370-xp-pmsu@d0022000 {
> - compatible = "marvell,armada-370-xp-pmsu";
> - reg = <0xd0022100 0x430>,
> -   <0xd0020800 0x20>;
> +armada-370-xp-pmsu@22000 {
> + compatible = "marvell,armada-370-pmsu";
> + reg = <0x22000 0x1000>;
>  };
>  
> diff --git a/arch/arm/boot/dts/armada-xp.dtsi 
> b/arch/arm/boot/dts/armada-xp.dtsi
> index abb9f9dcc525..0c455f5458df 100644
> --- a/arch/arm/boot/dts/armada-xp.dtsi
> +++ b/arch/arm/boot/dts/armada-xp.dtsi
> @@ -117,9 +117,14 @@
>   clock-names = "nbclk", "fixed";
>   };
>  
> - armada-370-xp-pmsu@22000 {
> - compatible = "marvell,armada-370-xp-pmsu";
> - reg = <0x22100 0x400>, <0x20800 0x20>;
> + cpurst@20800 {
> + compatible = "marvell,armada-xp-cpu-reset";
> + reg = <0x20800 0x20>;
> + };
> +
> + armada-370-pmsu@22000 {
> + compatible = "marvell,armada-370-pmsu";
> + reg = <0x22000 0x400>;
>   };
>  
>   eth2: ethernet@3 {
> -- 
> 1.8.1.2
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 07/14] ARM: mvebu: Extend the pmsu registers

[Jason Cooper]

On Tue, Mar 25, 2014 at 11:48:18PM +0100, Gregory CLEMENT wrote:
> The initial binding for PMSU were wrong. It didn't take into account
> all the registers from the PMSU and moreover it referred to registers
> which are not part of PMSU.
> 
> The Power Management Unit Service block also controls the Coherency
> Fabric subsystem. These registers are needed for the CPU idle
> implementation for the Armada 370/XP, it allows to enter a deep CPU
> idle state where the Coherency Fabric and the L2 cache are powered
> down.
> 
> This commit add support for a new compatible for the PMSU node
> including the block related to the coherency fabric. It also keeps
> compatibility with the old binding
> 
> This patch also adds warnings if one of the base registers set can't
> be ioremapped.
> 
> Signed-off-by: Gregory CLEMENT 
> ---
>  arch/arm/mach-mvebu/pmsu.c | 47 
> +-
>  1 file changed, 42 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/mach-mvebu/pmsu.c b/arch/arm/mach-mvebu/pmsu.c
> index d71ef53107c4..865bcb651e01 100644
> --- a/arch/arm/mach-mvebu/pmsu.c
> +++ b/arch/arm/mach-mvebu/pmsu.c
> @@ -27,11 +27,21 @@
>  static void __iomem *pmsu_mp_base;
>  static void __iomem *pmsu_reset_base;
>  
> -#define PMSU_BOOT_ADDR_REDIRECT_OFFSET(cpu)  ((cpu * 0x100) + 0x24)
> +#define PMSU_BASE_OFFSET0x100
> +#define PMSU_REG_SIZE0x1000
> +
> +#define PMSU_BOOT_ADDR_REDIRECT_OFFSET(cpu)  ((cpu * 0x100) + 0x124)
>  #define PMSU_RESET_CTL_OFFSET(cpu)   (cpu * 0x8)
>  
>  static struct of_device_id of_pmsu_table[] = {
> - {.compatible = "marvell,armada-370-xp-pmsu"},
> + {
> + .compatible = "marvell,armada-370-pmsu",
> + .data = (void *) false,

This looks sketchy to me.

> + },
> + {
> + .compatible = "marvell,armada-370-xp-pmsu",
> + .data = (void *) true, /* legacy */

Same.

> + },
>   { /* end of list */ },
>  };
>  
> @@ -59,15 +69,42 @@ int armada_xp_boot_cpu(unsigned int cpu_id, void 
> *boot_addr)
>  }
>  #endif
>  
> +static void __init armada_370_xp_pmsu_legacy_init(struct device_node *np)
> +{
> + u32 addr;
> + pr_warn("*** Warning ***  Using an old binding which will be 
> deprecated\n");

This should be noted in the binding docs...

> + /* We just need the adress, we already know the size */

nit. s/adress/address/

> + addr = be32_to_cpu(*of_get_address(np, 0, NULL, NULL));
> + addr -= PMSU_BASE_OFFSET;
> + pmsu_mp_base = ioremap(addr, PMSU_REG_SIZE);
> + of_node_put(np);
> +}
> +
>  static int __init armada_370_xp_pmsu_init(void)
>  {
>   struct device_node *np;
> -

Please leave this empty line.

>   np = of_find_matching_node(NULL, of_pmsu_table);
>   if (np) {
> + const struct of_device_id *match =
> + of_match_node(of_pmsu_table, np);
> + BUG_ON(!match);
> +
>   pr_info("Initializing Power Management Service Unit\n");
> - pmsu_mp_base = of_iomap(np, 0);
> - pmsu_reset_base = of_iomap(np, 1);
> +
> + if (match->data) /* legacy */
> + armada_370_xp_pmsu_legacy_init(np);

And if a new compatible string actually needs data passed?

> + else
> + pmsu_mp_base = of_iomap(np, 0);
> + WARN_ON(!pmsu_mp_base);
> + of_node_put(np);
> +
> + /*
> +  * This temporaty hack will be removed as soon as we

nit. s/temporaty/temporary/

thx,

Jason.

> +  * get the proper reset controler support
> +  */
> + np = of_find_compatible_node(NULL, NULL, 
> "marvell,armada-xp-cpu-reset");
> + pmsu_reset_base = of_iomap(np, 0);
> + WARN_ON(!pmsu_reset_base);
>   of_node_put(np);
>   }
>  
> -- 
> 1.8.1.2
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:x86/vdso] x86, vdso, build: Don' t rebuild 32-bit vdsos on every make

[tip-bot for Andy Lutomirski]

Commit-ID:  b9a4a56c1e5c72eac92d18aa48250a8c965632be
Gitweb: http://git.kernel.org/tip/b9a4a56c1e5c72eac92d18aa48250a8c965632be
Author: Andy Lutomirski 
AuthorDate: Tue, 25 Mar 2014 16:25:53 -0700
Committer:  H. Peter Anvin 
CommitDate: Tue, 25 Mar 2014 17:08:58 -0700

x86, vdso, build: Don't rebuild 32-bit vdsos on every make

vdso32/vclock_gettime.o was confusing kbuild.

Signed-off-by: Andy Lutomirski 
Cc: Stefani Seibold 
Link: 
http://lkml.kernel.org/r/d741449340642213744dd659471a35bb970a0c4c.1395789923.git.l...@amacapital.net
Signed-off-by: H. Peter Anvin 
---
 arch/x86/vdso/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/vdso/Makefile b/arch/x86/vdso/Makefile
index a2de5fc..6e6361a 100644
--- a/arch/x86/vdso/Makefile
+++ b/arch/x86/vdso/Makefile
@@ -136,7 +136,7 @@ override obj-dirs = $(dir $(obj)) $(obj)/vdso32/
 
 targets += vdso32/vdso32.lds
 targets += $(vdso32-images) $(vdso32-images:=.dbg)
-targets += vdso32/note.o $(vdso32.so-y:%=vdso32/%.o)
+targets += vdso32/note.o vdso32/vclock_gettime.o $(vdso32.so-y:%=vdso32/%.o)
 
 extra-y+= $(vdso32-images)
 
--
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 v2 8/9] net: filter: rework/optimize internal BPF interpreter's instruction set

[H. Peter Anvin]

On 03/25/2014 05:17 PM, David Miller wrote:
> From: Daniel Borkmann 
> Date: Tue, 25 Mar 2014 13:10:56 +0100
> 
>>   - Conditional jt/jf targets replaced with jt/fall-through,
>> and forward/backward jumps now possible as well
> 
> Ummm... does anyone even remember why backwards jumps were not allowed
> in the original BPF?
> 
> It's to guarentee forward progress in the filter.
> 
> Allowing branching backward would allow endless loops.
> 
> Please remove this feature.
> 

If you allow loops, it greatly increases the expressibility of the
language, but we would really need another control to limit CPU usage.

-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernfs/rtc: circular dependency between kernfs and ops_lock

[Sasha Levin]

On 03/25/2014 06:39 PM, Alessandro Zummo wrote:

On Tue, 25 Mar 2014 17:52:30 -0400
Sasha Levin  wrote:



   Pretty interesting indeed. One option would be to remove
   the sys files before acquiring the lock. But I wonder
   if this could lead to other issues.



Ping? Seems this thing got lost.


  What if we move

rtc_sysfs_del_device(rtc);

  before acquiring the lock?


Trying it now, I'll leave it going for a week and see if it reproduces.


Thanks,
Sasha

--
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: mm: slub: gpf in deactivate_slab

[Sasha Levin]

On 03/25/2014 02:10 PM, Christoph Lameter wrote:

On Tue, 25 Mar 2014, Sasha Levin wrote:


So here's the full trace. There's obviously something wrong here since we
pagefault inside the section that was supposed to be running with irqs
disabled
and I don't see another cause besides this.

The unreliable entries in the stack trace also somewhat suggest that the
fault is with the code I've pointed out.


Looks like there was some invalid data fed to the function and the page
fault with interrupts disabled is the result of following and invalid
pointer.

Is there more context information available? What are the options set for
the cache that the operation was performed on?


It seems like it's a regular allocation from the inode_cachep kmem_cache:

inode = kmem_cache_alloc(inode_cachep, GFP_KERNEL);

I'm not sure if there's anything special about this cache, codewise it's
created as follows:


inode_cachep = kmem_cache_create("inode_cache",
 sizeof(struct inode),
 0,
 (SLAB_RECLAIM_ACCOUNT|SLAB_PANIC|
 SLAB_MEM_SPREAD),
 init_once);


I'd be happy to dig up any other info required, I'm just not too sure
what you mean by options for the cache?


Thanks,
Sasha
--
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] x86, irq: get correct available vectors for cpu disable

[Yinghai Lu]

On Tue, Mar 25, 2014 at 1:03 PM, Linn Crosetto  wrote:
> Thanks for the patch.
>
> On Tue, Jan 28, 2014 at 01:54:05PM -0800, Yinghai Lu wrote:
>> used_vectors is a bitmap for vectors that are not tracked in per_cpu
>> vector_irq.
>
> I feel like this comment (also in the code) could be misleading because 
> vectors
> above first_system_vector are effectively not tracked in per_cpu vector_irq, 
> but
> also may not have the bit set in used_vectors. For example, used_vectors from 
> a
> system that I am looking at now:
>
> first_system_vector
> 239  255
>   |  |
>   10 01000 1 1
>
> test_bit(240, used_vectors) does not return the correct answer to the question
> about whether the vector is tracked in per_cpu vector_irq. This leads to two
> meanings for the bitmap; for vectors less than first_system_vector whether or
> not they are tracked in per_cpu vector_irq, and for vectors above
> first_system_vector, whether or not they are in use:
>
> static inline int is_per_cpu_vector(int vector) {
> return !test_bit(vector, used_vectors) &&
> vector < first_system_vector;
> }

sorry, I can not catch what you want to say.

Do you mean the change log or comment in the patch is not right?

Thanks

Yinghai
--
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 v2 8/9] net: filter: rework/optimize internal BPF interpreter's instruction set

[David Miller]

From: Daniel Borkmann 
Date: Tue, 25 Mar 2014 13:10:56 +0100

>   - Conditional jt/jf targets replaced with jt/fall-through,
> and forward/backward jumps now possible as well

Ummm... does anyone even remember why backwards jumps were not allowed
in the original BPF?

It's to guarentee forward progress in the filter.

Allowing branching backward would allow endless loops.

Please remove this feature.
--
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: gpf in simple_setattr

[Sasha Levin]

On 03/25/2014 05:12 PM, Jan Kara wrote:

On Tue 25-03-14 13:51:11, Sasha Levin wrote:

On 03/25/2014 01:33 PM, Jan Kara wrote:

On Mon 24-03-14 20:44:14, Sasha Levin wrote:

On 03/24/2014 05:48 PM, Jan Kara wrote:

[  339.948946] ** 4194304 8805ac03ba38 [eventpoll] 8806ec051fe0
[eventpoll] 84666040 88056c73e7b0   (null)

   OK, great. So finally we have something useful. We know we have problems
with [eventpoll] dentry. That is actually a special filesystem not mounted
anywhere - likely you get to that dentry through/proc//fd/. Now
eventpoll is interesting because it uses single anon inode for all
eventpoll instances. And that inode should stay in place as long as
eventpoll filesystem exists. So it's not clear how come that inode is
freed. The basic check of handling of inode use count didn't find anything
suspicious. But I can check in more detail and if I fail, we now have a
pretty narrow area where to look...


Seems like it's not specific to eventpoll, I saw the same error message with
"eventfd" and "perf_event".

   Yup, all these use anon_inode_getfile() so it all points to the fact that
for some reason we freed anon_inode_inode. But I don't see where the
problem is. Can you maybe make 'anon_inode_inode' external to
fs/anon_inodes.c and dump stack for all iput() calls to anon_inode_inode?
There must be some suckers which don't belong there...


Okay, this is straightforward. It happened right after boot so we're lucky.

I'm also looking into that, but odds you'll spot the issue faster than me.

   Can you try whether the following patch fixes the issue for you?


Looks like it fixes it, thanks!


Thanks,
Sasha

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Fix late crypto work queue initialization

[Greg Kroah-Hartman]

On Tue, Mar 25, 2014 at 04:40:56PM -0700, Tim Chen wrote:
> On Fri, 2014-03-21 at 22:40 +0800, Herbert Xu wrote:
> > On Mon, Mar 17, 2014 at 04:52:26PM -0700, Tim Chen wrote:
> > > The crypto algorithm modules utilizing the crypto daemon could
> > > be used early when the system start up.  Using module_init
> > > does not guarantee that the daemon's work queue is initialized
> > > when the cypto alorithm depending on crypto_wq starts.  It is necessary
> > > to initialize the crypto work queue earlier at the subsystem
> > > init time to make sure that it is initialized
> > > when used.
> > > 
> > > Signed-off-by: Tim Chen 
> > 
> > Patch applied.
> 
> Herbert,
> 
> Probably this patch should go to the stable patches as well.
> Copying Greg.



This is not the correct way to submit patches for inclusion in the
stable kernel tree.  Please read Documentation/stable_kernel_rules.txt
for how to do this properly.


--
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: mvsdio: unhandled interrupt, mmc writes queuing up

[Jason Cooper]

On Tue, Mar 25, 2014 at 11:16:53PM +0100, Sebastian Hesselbarth wrote:
> On 03/25/2014 08:27 PM, Alexander Elbs wrote:
> >> On Wed, 19 Mar 2014, Bruno Prémont wrote:
> >>> Since upgrading my Sheevaplug from 3.7.2 to 3.13.6 (FDT) I'm seeing
> >>>   mvsdio f109.mvsdio: unhandled interrupt status=0x8810 en=0x 
> >>> pio=0
> >>> at varied timings.
> > 
> > I have the same problem on my sheevaplug.
> > 
> >> It has been many years since I've looked at the code for this driver.  
> >> I'm therefore including Thomas Petazzoni to the CC list as he appears to 
> >> have been the most active since then.
> >>
> >> The reported status seems to indicate missing data in the context of a 
> >> transfer with CMD12, and a CRC error ensued of course.
> >>
> >> At this point I'd suggest testing intermediate kernels between 3.7 and 
> >> 3.13, and try bisection until you find the offending commit.
> >>
> >> [...]
> >>> I get same results with 3.14-rc7.
> >>
> >> Excellent, that reduces the search space significantly.  You can do a 
> >> git bisect directly.
> > 
> > I did a git bisect.
> >   good: no message "unhandled interrupt"
> >   bad: message above appears
> >   skipped: unbootable kernel, usually stuck after the line "Uncompressing 
> > Linux". 
> > 
> > So far I am down to a few commits after 3.11.
> > 
> > $ git bisect view --oneline
> > 2326f04 (refs/bisect/bad) ARM: kirkwood: convert to DT irqchip and 
> > clocksource
> 
> Can you please try the patches contained in [1]?
> 
> They have been Acked-by Jason Cooper, but I guess we simply lost
> track of them.
> 
> Sebastian
> 
> [1] https://lkml.org/lkml/2013/11/15/276

Bruno,

If these work for you, please send a Tested-by and I'll keep better
track of them this time.  I think these were sent before we had a
process for shuttling things into irqchip...

thx,

Jason.
--
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:irq/core] ARM: sun7i/sun6i: irqchip: Add irqchip driver for NMI controller

[tip-bot for Carlo Caione]

Commit-ID:  6058bb362818e09990de722e983a7f2874e7f61c
Gitweb: http://git.kernel.org/tip/6058bb362818e09990de722e983a7f2874e7f61c
Author: Carlo Caione 
AuthorDate: Wed, 19 Mar 2014 20:21:17 +0100
Committer:  Thomas Gleixner 
CommitDate: Wed, 26 Mar 2014 01:00:50 +0100

ARM: sun7i/sun6i: irqchip: Add irqchip driver for NMI controller

Allwinner A20/A31 SoCs have special registers to control / (un)mask /
acknowledge NMI. This NMI controller is separated and independent from GIC.
This patch adds a new irqchip to manage NMI.

Signed-off-by: Carlo Caione 
Acked-by: Maxime Ripard 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-su...@googlegroups.com
Cc: mark.rutl...@arm.com
Cc: hdego...@redhat.com
Link: http://lkml.kernel.org/r/1395256879-8475-2-git-send-email-ca...@caione.org
Signed-off-by: Thomas Gleixner 
---
 drivers/irqchip/Makefile|   1 +
 drivers/irqchip/irq-sunxi-nmi.c | 208 
 2 files changed, 209 insertions(+)

diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 5194afb..1c0c151 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -12,6 +12,7 @@ obj-$(CONFIG_METAG_PERFCOUNTER_IRQS)  += irq-metag.o
 obj-$(CONFIG_ARCH_MOXART)  += irq-moxart.o
 obj-$(CONFIG_ORION_IRQCHIP)+= irq-orion.o
 obj-$(CONFIG_ARCH_SUNXI)   += irq-sun4i.o
+obj-$(CONFIG_ARCH_SUNXI)   += irq-sunxi-nmi.o
 obj-$(CONFIG_ARCH_SPEAR3XX)+= spear-shirq.o
 obj-$(CONFIG_ARM_GIC)  += irq-gic.o
 obj-$(CONFIG_ARM_NVIC) += irq-nvic.o
diff --git a/drivers/irqchip/irq-sunxi-nmi.c b/drivers/irqchip/irq-sunxi-nmi.c
new file mode 100644
index 000..1c8566c
--- /dev/null
+++ b/drivers/irqchip/irq-sunxi-nmi.c
@@ -0,0 +1,208 @@
+/*
+ * Allwinner A20/A31 SoCs NMI IRQ chip driver.
+ *
+ * Carlo Caione 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2.  This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "irqchip.h"
+
+#define SUNXI_NMI_SRC_TYPE_MASK0x0003
+
+enum {
+   SUNXI_SRC_TYPE_LEVEL_LOW = 0,
+   SUNXI_SRC_TYPE_EDGE_FALLING,
+   SUNXI_SRC_TYPE_LEVEL_HIGH,
+   SUNXI_SRC_TYPE_EDGE_RISING,
+};
+
+struct sunxi_sc_nmi_reg_offs {
+   u32 ctrl;
+   u32 pend;
+   u32 enable;
+};
+
+static struct sunxi_sc_nmi_reg_offs sun7i_reg_offs = {
+   .ctrl   = 0x00,
+   .pend   = 0x04,
+   .enable = 0x08,
+};
+
+static struct sunxi_sc_nmi_reg_offs sun6i_reg_offs = {
+   .ctrl   = 0x00,
+   .pend   = 0x04,
+   .enable = 0x34,
+};
+
+static inline void sunxi_sc_nmi_write(struct irq_chip_generic *gc, u32 off,
+ u32 val)
+{
+   irq_reg_writel(val, gc->reg_base + off);
+}
+
+static inline u32 sunxi_sc_nmi_read(struct irq_chip_generic *gc, u32 off)
+{
+   return irq_reg_readl(gc->reg_base + off);
+}
+
+static void sunxi_sc_nmi_handle_irq(unsigned int irq, struct irq_desc *desc)
+{
+   struct irq_domain *domain = irq_desc_get_handler_data(desc);
+   struct irq_chip *chip = irq_get_chip(irq);
+   unsigned int virq = irq_find_mapping(domain, 0);
+
+   chained_irq_enter(chip, desc);
+   generic_handle_irq(virq);
+   chained_irq_exit(chip, desc);
+}
+
+static int sunxi_sc_nmi_set_type(struct irq_data *data, unsigned int flow_type)
+{
+   struct irq_chip_generic *gc = irq_data_get_irq_chip_data(data);
+   struct irq_chip_type *ct = gc->chip_types;
+   u32 src_type_reg;
+   u32 ctrl_off = ct->regs.type;
+   unsigned int src_type;
+   unsigned int i;
+
+   irq_gc_lock(gc);
+
+   switch (flow_type & IRQF_TRIGGER_MASK) {
+   case IRQ_TYPE_EDGE_FALLING:
+   src_type = SUNXI_SRC_TYPE_EDGE_FALLING;
+   break;
+   case IRQ_TYPE_EDGE_RISING:
+   src_type = SUNXI_SRC_TYPE_EDGE_RISING;
+   break;
+   case IRQ_TYPE_LEVEL_HIGH:
+   src_type = SUNXI_SRC_TYPE_LEVEL_HIGH;
+   break;
+   case IRQ_TYPE_NONE:
+   case IRQ_TYPE_LEVEL_LOW:
+   src_type = SUNXI_SRC_TYPE_LEVEL_LOW;
+   break;
+   default:
+   irq_gc_unlock(gc);
+   pr_err("%s: Cannot assign multiple trigger modes to IRQ %d.\n",
+   __func__, data->irq);
+   return -EBADR;
+   }
+
+   irqd_set_trigger_type(data, flow_type);
+   irq_setup_alt_chip(data, flow_type);
+
+   for (i = 0; i <= gc->num_ct; i++, ct++)
+   if (ct->type & flow_type)
+   ctrl_off = ct->regs.type;
+
+   src_type_reg = sunxi_sc_nmi_read(gc, ctrl_off);
+   src_type_reg &= ~SUNXI_NMI_SRC_TYPE_MASK;
+   src_type_reg |= src_type;
+   sunxi_sc_nmi_write(gc, ctrl_off, 

[tip:irq/core] ARM: sun7i/sun6i: irqchip: Update the documentation

[tip-bot for Carlo Caione]

Commit-ID:  ae7d9d3245b7ced5c6f615cfef1250226d518436
Gitweb: http://git.kernel.org/tip/ae7d9d3245b7ced5c6f615cfef1250226d518436
Author: Carlo Caione 
AuthorDate: Wed, 19 Mar 2014 20:21:19 +0100
Committer:  Thomas Gleixner 
CommitDate: Wed, 26 Mar 2014 01:00:50 +0100

ARM: sun7i/sun6i: irqchip: Update the documentation

Add documentation for NMI irqchip.

Signed-off-by: Carlo Caione 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-su...@googlegroups.com
Cc: mark.rutl...@arm.com
Cc: hdego...@redhat.com
Acked-by: maxime.rip...@free-electrons.com
Link: http://lkml.kernel.org/r/1395256879-8475-4-git-send-email-ca...@caione.org
Signed-off-by: Thomas Gleixner 
---
 .../allwinner,sun67i-sc-nmi.txt| 27 ++
 1 file changed, 27 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun67i-sc-nmi.txt
 
b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun67i-sc-nmi.txt
new file mode 100644
index 000..d1c5cda
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/interrupt-controller/allwinner,sun67i-sc-nmi.txt
@@ -0,0 +1,27 @@
+Allwinner Sunxi NMI Controller
+==
+
+Required properties:
+
+- compatible : should be "allwinner,sun7i-a20-sc-nmi" or
+  "allwinner,sun6i-a31-sc-nmi"
+- reg : Specifies base physical address and size of the registers.
+- interrupt-controller : Identifies the node as an interrupt controller
+- #interrupt-cells : Specifies the number of cells needed to encode an
+  interrupt source. The value shall be 2. The first cell is the IRQ number, the
+  second cell the trigger type as defined in interrupt.txt in this directory.
+- interrupt-parent: Specifies the parent interrupt controller.
+- interrupts: Specifies the interrupt line (NMI) which is handled by
+  the interrupt controller in the parent controller's notation. This value
+  shall be the NMI.
+
+Example:
+
+sc-nmi-intc@01c00030 {
+   compatible = "allwinner,sun7i-a20-sc-nmi";
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   reg = <0x01c00030 0x0c>;
+   interrupt-parent = <>;
+   interrupts = <0 0 4>;
+};
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[tip:irq/core] ARM: sun7i/sun6i: dts: Add NMI irqchip support

[tip-bot for Carlo Caione]

Commit-ID:  8ff973a26763ef2f2d45c1649c618dfff528a502
Gitweb: http://git.kernel.org/tip/8ff973a26763ef2f2d45c1649c618dfff528a502
Author: Carlo Caione 
AuthorDate: Wed, 19 Mar 2014 20:21:18 +0100
Committer:  Thomas Gleixner 
CommitDate: Wed, 26 Mar 2014 01:00:50 +0100

ARM: sun7i/sun6i: dts: Add NMI irqchip support

This patch adds DTS entries for NMI controller as child of GIC.

Signed-off-by: Carlo Caione 
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-su...@googlegroups.com
Cc: mark.rutl...@arm.com
Cc: hdego...@redhat.com
Acked-by: maxime.rip...@free-electrons.com
Link: http://lkml.kernel.org/r/1395256879-8475-3-git-send-email-ca...@caione.org
Signed-off-by: Thomas Gleixner 
---
 arch/arm/boot/dts/sun6i-a31.dtsi | 8 
 arch/arm/boot/dts/sun7i-a20.dtsi | 8 
 2 files changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/sun6i-a31.dtsi b/arch/arm/boot/dts/sun6i-a31.dtsi
index 5256ad9..eea6033 100644
--- a/arch/arm/boot/dts/sun6i-a31.dtsi
+++ b/arch/arm/boot/dts/sun6i-a31.dtsi
@@ -190,6 +190,14 @@
#size-cells = <1>;
ranges;
 
+   nmi_intc: interrupt-controller@01f00c0c {
+   compatible = "allwinner,sun6i-a31-sc-nmi";
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   reg = <0x01f00c0c 0x38>;
+   interrupts = <0 0 4>;
+   };
+
pio: pinctrl@01c20800 {
compatible = "allwinner,sun6i-a31-pinctrl";
reg = <0x01c20800 0x400>;
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index 6f25cf5..7637f12 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -339,6 +339,14 @@
#size-cells = <1>;
ranges;
 
+   nmi_intc: interrupt-controller@01c00030 {
+   compatible = "allwinner,sun7i-a20-sc-nmi";
+   interrupt-controller;
+   #interrupt-cells = <2>;
+   reg = <0x01c00030 0x0c>;
+   interrupts = <0 0 4>;
+   };
+
emac: ethernet@01c0b000 {
compatible = "allwinner,sun4i-a10-emac";
reg = <0x01c0b000 0x1000>;
--
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: Add support for multi register mux

[Arun Shamanna Lakshmi]

If the mux uses 1 bit position per input, and requires to set one
single bit at a time, then an N bit register can support up to N
inputs. In more recent Tegra chips, we have at least greater than
64 inputs which requires at least 2 .reg fields in struct soc_enum.

Signed-off-by: Arun Shamanna Lakshmi 
Signed-off-by: Songhee Baek 
---
 include/sound/soc-dapm.h |   20 +-
 include/sound/soc.h  |   44 ++---
 sound/soc/soc-core.c |  118 +--
 sound/soc/soc-dapm.c |  155 +++---
 4 files changed, 300 insertions(+), 37 deletions(-)

diff --git a/include/sound/soc-dapm.h b/include/sound/soc-dapm.h
index ef78f56..324de75 100644
--- a/include/sound/soc-dapm.h
+++ b/include/sound/soc-dapm.h
@@ -315,6 +315,12 @@ struct device;
.private_value = (unsigned long) }
 #define SOC_DAPM_VALUE_ENUM(xname, xenum) \
SOC_DAPM_ENUM(xname, xenum)
+#define SOC_DAPM_VALUE_ENUM_WIDE(xname, xenum) \
+{  .iface = SNDRV_CTL_ELEM_IFACE_MIXER, .name = xname, \
+   .info = snd_soc_info_enum_wide, \
+   .get = snd_soc_dapm_get_value_enum_wide, \
+   .put = snd_soc_dapm_put_value_enum_wide, \
+   .private_value = (unsigned long) }
 #define SOC_DAPM_PIN_SWITCH(xname) \
 {  .iface = SNDRV_CTL_ELEM_IFACE_MIXER, .name = xname " Switch", \
.info = snd_soc_dapm_info_pin_switch, \
@@ -352,6 +358,9 @@ struct device;
 /* regulator widget flags */
 #define SND_SOC_DAPM_REGULATOR_BYPASS 0x1 /* bypass when disabled */
 
+/* maximum number of registers to update */
+#define SOC_DAPM_UPDATE_MAX_REGS 3
+
 struct snd_soc_dapm_widget;
 enum snd_soc_dapm_type;
 struct snd_soc_dapm_path;
@@ -378,6 +387,10 @@ int snd_soc_dapm_get_enum_double(struct snd_kcontrol 
*kcontrol,
struct snd_ctl_elem_value *ucontrol);
 int snd_soc_dapm_put_enum_double(struct snd_kcontrol *kcontrol,
struct snd_ctl_elem_value *ucontrol);
+int snd_soc_dapm_get_value_enum_wide(struct snd_kcontrol *kcontrol,
+   struct snd_ctl_elem_value *ucontrol);
+int snd_soc_dapm_put_value_enum_wide(struct snd_kcontrol *kcontrol,
+   struct snd_ctl_elem_value *ucontrol);
 int snd_soc_dapm_info_pin_switch(struct snd_kcontrol *kcontrol,
struct snd_ctl_elem_info *uinfo);
 int snd_soc_dapm_get_pin_switch(struct snd_kcontrol *kcontrol,
@@ -590,9 +603,10 @@ struct snd_soc_dapm_widget {
 
 struct snd_soc_dapm_update {
struct snd_kcontrol *kcontrol;
-   int reg;
-   int mask;
-   int val;
+   int reg[SOC_DAPM_UPDATE_MAX_REGS];
+   int mask[SOC_DAPM_UPDATE_MAX_REGS];
+   int val[SOC_DAPM_UPDATE_MAX_REGS];
+   int num_regs;
 };
 
 /* DAPM context */
diff --git a/include/sound/soc.h b/include/sound/soc.h
index 0b83168..67097c6 100644
--- a/include/sound/soc.h
+++ b/include/sound/soc.h
@@ -177,16 +177,22 @@
{.reg = xreg, .min = xmin, .max = xmax, \
 .platform_max = xmax} }
 #define SOC_ENUM_DOUBLE(xreg, xshift_l, xshift_r, xitems, xtexts) \
-{  .reg = xreg, .shift_l = xshift_l, .shift_r = xshift_r, \
+{  .reg[0] = xreg, .shift_l = xshift_l, .shift_r = xshift_r, \
.items = xitems, .texts = xtexts, \
-   .mask = xitems ? roundup_pow_of_two(xitems) - 1 : 0}
+   .mask[0] = xitems ? roundup_pow_of_two(xitems) - 1 : 0, .num_regs = 1 }
 #define SOC_ENUM_SINGLE(xreg, xshift, xitems, xtexts) \
SOC_ENUM_DOUBLE(xreg, xshift, xshift, xitems, xtexts)
 #define SOC_ENUM_SINGLE_EXT(xitems, xtexts) \
 {  .items = xitems, .texts = xtexts }
+#define SOC_VALUE_ENUM_TRIPLE(reg1, reg2, reg3, mask1, mask2, mask3, \
+   nreg, nmax, xtexts, xvalues) \
+{  .reg[0] = reg1, .reg[1] = reg2, .reg[2] = reg3, \
+   .mask[0] = mask1, .mask[1] = mask2, .mask[2] = mask3, \
+   .num_regs = nreg, .items = nmax, .texts = xtexts, .values = xvalues }
 #define SOC_VALUE_ENUM_DOUBLE(xreg, xshift_l, xshift_r, xmask, xitems, xtexts, 
xvalues) \
-{  .reg = xreg, .shift_l = xshift_l, .shift_r = xshift_r, \
-   .mask = xmask, .items = xitems, .texts = xtexts, .values = xvalues}
+{  .reg[0] = xreg, .shift_l = xshift_l, .shift_r = xshift_r, \
+   .mask[0] = xmask, .items = xitems, .texts = xtexts, .values = xvalues,\
+   .num_regs = 1 }
 #define SOC_VALUE_ENUM_SINGLE(xreg, xshift, xmask, xnitmes, xtexts, xvalues) \
SOC_VALUE_ENUM_DOUBLE(xreg, xshift, xshift, xmask, xnitmes, xtexts, 
xvalues)
 #define SOC_ENUM_SINGLE_VIRT(xitems, xtexts) \
@@ -198,6 +204,12 @@
.private_value = (unsigned long) }
 #define SOC_VALUE_ENUM(xname, xenum) \
SOC_ENUM(xname, xenum)
+#define SOC_VALUE_ENUM_WIDE(xname, xenum) \
+{  .iface = SNDRV_CTL_ELEM_IFACE_MIXER, .name = xname,\
+   .info = snd_soc_info_enum_wide, \
+   .get = snd_soc_get_value_enum_wide, \
+   .put = snd_soc_put_value_enum_wide, \
+   .private_value = (unsigned long) }
 #define SOC_SINGLE_EXT(xname, xreg, xshift, xmax, xinvert,\
   

[tip:timers/core] tick: Remove code duplication in tick_handle_periodic()

[tip-bot for Viresh Kumar]

Commit-ID:  b97f0291a2504291aef850077f98cab68a5a2f33
Gitweb: http://git.kernel.org/tip/b97f0291a2504291aef850077f98cab68a5a2f33
Author: Viresh Kumar 
AuthorDate: Tue, 25 Mar 2014 13:56:23 +0530
Committer:  Thomas Gleixner 
CommitDate: Wed, 26 Mar 2014 00:56:49 +0100

tick: Remove code duplication in tick_handle_periodic()

tick_handle_periodic() is calling ktime_add() at two places, first before the
infinite loop and then at the end of infinite loop. We can rearrange code a bit
to fix code duplication here.

It looks quite simple and shouldn't break anything, I guess :)

Signed-off-by: Viresh Kumar 
Cc: linaro-ker...@lists.linaro.org
Cc: fweis...@gmail.com
Link: 
http://lkml.kernel.org/r/be3481e8f3f71df694a4b43623254fc93ca51b59.1395735873.git.viresh.ku...@linaro.org
Signed-off-by: Thomas Gleixner 
---
 kernel/time/tick-common.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
index 0fec634..0156612 100644
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@ -98,18 +98,19 @@ static void tick_periodic(int cpu)
 void tick_handle_periodic(struct clock_event_device *dev)
 {
int cpu = smp_processor_id();
-   ktime_t next;
+   ktime_t next = dev->next_event;
 
tick_periodic(cpu);
 
if (dev->mode != CLOCK_EVT_MODE_ONESHOT)
return;
-   /*
-* Setup the next period for devices, which do not have
-* periodic mode:
-*/
-   next = ktime_add(dev->next_event, tick_period);
for (;;) {
+   /*
+* Setup the next period for devices, which do not have
+* periodic mode:
+*/
+   next = ktime_add(next, tick_period);
+
if (!clockevents_program_event(dev, next, false))
return;
/*
@@ -123,7 +124,6 @@ void tick_handle_periodic(struct clock_event_device *dev)
 */
if (timekeeping_valid_for_hres())
tick_periodic(cpu);
-   next = ktime_add(next, tick_period);
}
 }
 
--
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] tick: Fix spelling mistake in tick_handle_periodic()

[tip-bot for Viresh Kumar]

Commit-ID:  cacb3c76c2012ade52124e8c6fdc5cb125625772
Gitweb: http://git.kernel.org/tip/cacb3c76c2012ade52124e8c6fdc5cb125625772
Author: Viresh Kumar 
AuthorDate: Tue, 25 Mar 2014 16:09:18 +0530
Committer:  Thomas Gleixner 
CommitDate: Wed, 26 Mar 2014 00:56:49 +0100

tick: Fix spelling mistake in tick_handle_periodic()

One of the comments in tick_handle_periodic() had 'when' instead of 'which' (My
guess :)). Fix it.

Also fix spelling mistake in 'Possible'.

Signed-off-by: Viresh Kumar 
Cc: linaro-ker...@lists.linaro.org
Cc: skarafo...@gmail.com
Link: 
http://lkml.kernel.org/r/2b29ca4230c163e44179941d7c7a16c1474385c2.1395743878.git.viresh.ku...@linaro.org
Signed-off-by: Thomas Gleixner 
---
 kernel/time/tick-common.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/time/tick-common.c b/kernel/time/tick-common.c
index 20b2fe3..0fec634 100644
--- a/kernel/time/tick-common.c
+++ b/kernel/time/tick-common.c
@@ -118,7 +118,7 @@ void tick_handle_periodic(struct clock_event_device *dev)
 * to be sure we're using a real hardware clocksource.
 * Otherwise we could get trapped in an infinite
 * loop, as the tick_periodic() increments jiffies,
-* when then will increment time, posibly causing
+* which then will increment time, possibly causing
 * the loop to trigger again and again.
 */
if (timekeeping_valid_for_hres())
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 2/2] ARM hibernation / suspend-to-disk

[Alexander Holler]

Am 26.03.2014 00:36, schrieb Alexander Holler:

Am 25.03.2014 19:38, schrieb Alexander Holler:


reboot too. Another solution would be to unregister the reboot_notifier
in the reboot_nofifier itself. I've just seen one watchdog driver
(drivers/rtc/rtc-m41t80.c) which does that. But I still think such


That, btw. is broken. ;)

Right after having send the mail, I've became that intuition, had a look
and ... notifier.h does state the following:

  * atomic_notifier_chain_unregister(),
blocking_notifier_chain_unregister(),
  * and srcu_notifier_chain_unregister() _must not_ be called from within
  * the call chain.

(The reboot-notifier chain is of type blocking_notifier_chain)

So I've picked up one user of reboot_notifier by random and had the luck
to choose a broken one. ;)

I will make a patch and will have a look if the same failure can be
found elsewhere. There aren't that much users of the reboot-notifier, so
it shouldn't cost me that much time.


Hmm, and either I was confused, or have looked at some other user of the 
reboot_notifier, but rtc-m41t80.c doesn't call unregister from it's 
notifier. And unfortunately there are a bit more users of the 
reboot_notifier than I first thought. :/


I will check if I can find out at least at which driver I had a look at 
which did call unregister_notifier from the notifier itself.


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: [PATCH] #CleanUp non-gender-neutral README

[Valdis . Kletnieks]

On Mon, 24 Mar 2014 01:09:16 -, Feminist Software Foundation said:
>  From: Feminist-Software-Foundation
> 

The merge window is expected to open *next* week, around Monday or Tuesday.
Please resubmit then.


pgpNc2_MhLJ7W.pgp
Description: PGP signature

[PATCH 2/2] pinctrl: rockchip: handle first half of rk3188-bank0 correctly

[Heiko Stübner]

The first half of pinbank 0 only has one muxing function (as gpios) and
does not have a special mux-register.

Therefore ensure that no other mux function can be selected and also do not
write to a non-existent register.

Signed-off-by: Heiko Stuebner 
---
 drivers/pinctrl/pinctrl-rockchip.c | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/drivers/pinctrl/pinctrl-rockchip.c 
b/drivers/pinctrl/pinctrl-rockchip.c
index 80e28e5..ffcd4f4 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -350,6 +350,20 @@ static int rockchip_set_mux(struct rockchip_pin_bank 
*bank, int pin, int mux)
u8 bit;
u32 data;
 
+   /*
+* The first 16 pins of rk3188_bank0 are always gpios and do not have
+* a mux register at all.
+*/
+   if (bank->bank_type == RK3188_BANK0 && pin < 16) {
+   if (mux != RK_FUNC_GPIO) {
+   dev_err(info->dev,
+   "pin %d only supports a gpio mux\n", pin);
+   return -ENOTSUPP;
+   } else {
+   return 0;
+   }
+   }
+
dev_dbg(info->dev, "setting mux of GPIO%d-%d to %d\n",
bank->bank_num, pin, mux);
 
-- 
1.9.0


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] pinctrl: rockchip: add return value to rockchip_set_mux

[Heiko Stübner]

In a following change, rockchip_set_mux gets the possibility to fail.
Therefore add a return value to it and honor error codes in functions
using rockchip_set_mux.

Signed-off-by: Heiko Stuebner 
---
 drivers/pinctrl/pinctrl-rockchip.c | 32 +---
 1 file changed, 25 insertions(+), 7 deletions(-)

diff --git a/drivers/pinctrl/pinctrl-rockchip.c 
b/drivers/pinctrl/pinctrl-rockchip.c
index 23e8812..80e28e5 100644
--- a/drivers/pinctrl/pinctrl-rockchip.c
+++ b/drivers/pinctrl/pinctrl-rockchip.c
@@ -342,7 +342,7 @@ static const struct pinctrl_ops rockchip_pctrl_ops = {
  * @pin: pin to change
  * @mux: new mux function to set
  */
-static void rockchip_set_mux(struct rockchip_pin_bank *bank, int pin, int mux)
+static int rockchip_set_mux(struct rockchip_pin_bank *bank, int pin, int mux)
 {
struct rockchip_pinctrl *info = bank->drvdata;
void __iomem *reg = info->reg_base + info->ctrl->mux_offset;
@@ -365,6 +365,8 @@ static void rockchip_set_mux(struct rockchip_pin_bank 
*bank, int pin, int mux)
writel(data, reg);
 
spin_unlock_irqrestore(>slock, flags);
+
+   return 0;
 }
 
 #define RK2928_PULL_OFFSET 0x118
@@ -560,7 +562,7 @@ static int rockchip_pmx_enable(struct pinctrl_dev *pctldev, 
unsigned selector,
const unsigned int *pins = info->groups[group].pins;
const struct rockchip_pin_config *data = info->groups[group].data;
struct rockchip_pin_bank *bank;
-   int cnt;
+   int cnt, ret = 0;
 
dev_dbg(info->dev, "enable function %s group %s\n",
info->functions[selector].name, info->groups[group].name);
@@ -571,8 +573,18 @@ static int rockchip_pmx_enable(struct pinctrl_dev 
*pctldev, unsigned selector,
 */
for (cnt = 0; cnt < info->groups[group].npins; cnt++) {
bank = pin_to_bank(info, pins[cnt]);
-   rockchip_set_mux(bank, pins[cnt] - bank->pin_base,
-data[cnt].func);
+   ret = rockchip_set_mux(bank, pins[cnt] - bank->pin_base,
+  data[cnt].func);
+   if (ret)
+   break;
+   }
+
+   if (ret) {
+   /* revert the already done pin settings */
+   for (cnt--; cnt >= 0; cnt--)
+   rockchip_set_mux(bank, pins[cnt] - bank->pin_base, 0);
+
+   return ret;
}
 
return 0;
@@ -607,7 +619,7 @@ static int rockchip_pmx_gpio_set_direction(struct 
pinctrl_dev *pctldev,
struct rockchip_pinctrl *info = pinctrl_dev_get_drvdata(pctldev);
struct rockchip_pin_bank *bank;
struct gpio_chip *chip;
-   int pin;
+   int pin, ret;
u32 data;
 
chip = range->gc;
@@ -617,7 +629,9 @@ static int rockchip_pmx_gpio_set_direction(struct 
pinctrl_dev *pctldev,
dev_dbg(info->dev, "gpio_direction for pin %u as %s-%d to %s\n",
 offset, range->name, pin, input ? "input" : "output");
 
-   rockchip_set_mux(bank, pin, RK_FUNC_GPIO);
+   ret = rockchip_set_mux(bank, pin, RK_FUNC_GPIO);
+   if (ret < 0)
+   return ret;
 
data = readl_relaxed(bank->reg_base + GPIO_SWPORT_DDR);
/* set bit to 1 for output, 0 for input */
@@ -1144,9 +1158,13 @@ static int rockchip_irq_set_type(struct irq_data *d, 
unsigned int type)
u32 polarity;
u32 level;
u32 data;
+   int ret;
 
/* make sure the pin is configured as gpio input */
-   rockchip_set_mux(bank, d->hwirq, RK_FUNC_GPIO);
+   ret = rockchip_set_mux(bank, d->hwirq, RK_FUNC_GPIO);
+   if (ret < 0)
+   return ret;
+
data = readl_relaxed(bank->reg_base + GPIO_SWPORT_DDR);
data &= ~mask;
writel_relaxed(data, bank->reg_base + GPIO_SWPORT_DDR);
-- 
1.9.0


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/2] pinctrl: rockchip: fix handling of first pinbank

[Heiko Stübner]

Am Dienstag, 25. März 2014, 20:43:59 schrieb Beniamino Galvani:
> On Tue, Mar 25, 2014 at 12:14:42AM +0100, Heiko Stübner wrote:
> > GPIO0 only has the second two IOMUX registers:
> > - GRF_GPIO0C_IOMUX at 0x68
> > - GRF_GPIO0D_IOMUX at 0x6c
> > which I guess is where my mistake comes from.

[...] 

> On radxa rock schematic pins GPIO0A* and GPIO0B* are labeled only as
> gpios, without alternate functions like other pins; my guess is that
> on rk3188 they can only act as gpios and so mux registers are not
> needed for them.

That was my guess too - especially as the registers are also missing.

Therefore I put together the following two patches to go on top of
your patch and also make rockchip_set_mux honor this situation.


Heiko Stuebner (2):
  pinctrl: rockchip: add return value to rockchip_set_mux
  pinctrl: rockchip: handle first half of rk3188-bank0 correctly

 drivers/pinctrl/pinctrl-rockchip.c | 46 --
 1 file changed, 39 insertions(+), 7 deletions(-)

-- 
1.9.0


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/4] Set max_discard_sectors maximal value to UINT_MAX>>9

[Gwendal Grignou]

Without this change, 'blkdiscard /dev/mmcblk0' would panic:
Because max_discard_sectors was set to 4G sectors, discard request issued
on behalf of blkdiscard would be merged, leading to request larger than 4GB:
[  169.035929] __end_that: dev mmcblk0: type=1, flags=122c8081
[  169.041464]   sector 0, nr/cnr 0/4294966272
[  169.045689]   bio ebb7a380, biotail ebb7aa80, buffer   (null), len 0
[  169.052106] blk_update_request: bio idx 0 >= vcnt 0
[  169.057068] request botched: dev mmcblk0: type=1, flags=122c8081
[  169.063138]   sector 0, nr/cnr 0/4294966272
[  169.067436]   bio ebb7a380, biotail ebb7aa80, buffer   (null), len 0
The IOCTL would be stuck in the kernel, a watchdog would reboot the machine.

After this change, blkdiscard works fine. With blktrace/blkparse, I verified
the discard requests are sane: 8387584 is 4GB in sectors rounded down.
Example of a ~16GB device:
 9368  Q   D 0 + 8387584 [blkdiscard]
0  m   N cfq9368 alloced
 9368  G   D 0 + 8387584 [blkdiscard]
 9368  P   N [blkdiscard]
 9368  Q   D 8387584 + 8387584 [blkdiscard]
 9368  G   D 8387584 + 8387584 [blkdiscard]
 9368  Q   D 16775168 + 8387584 [blkdiscard]
 9368  G   D 16775168 + 8387584 [blkdiscard]
 9368  Q   D 25162752 + 5372928 [blkdiscard]
 9368  G   D 25162752 + 5372928 [blkdiscard]
 9368  I   D 0 + 8387584 [blkdiscard]
0  m   N cfq9368 insert_request
0  m   N cfq9368 add_to_rr
 9368  I   D 8387584 + 8387584 [blkdiscard]
0  m   N cfq9368 insert_request
 9368  I   D 16775168 + 8387584 [blkdiscard]
0  m   N cfq9368 insert_request
 9368  I   D 25162752 + 5372928 [blkdiscard]
0  m   N cfq9368 insert_request
 9368  U   N [blkdiscard] 4
 ...

I fixed the other locations where max_discard_sectors was set to
UINT_MAX and checked the other settings were in units of 512 bytes
sectors.

Gwendal Grignou (4):
  Limit max_discard_sectors to UINT_MAX>>9
  Limit max_discard_sectors to UINT_MAX>>9
  Limit max_discard_sectors to UINT_MAX>>9
  Limit max_discard_sectors to UINT_MAX>>9

 block/blk-lib.c   | 2 +-
 drivers/block/nbd.c   | 2 +-
 drivers/mmc/core/core.c   | 6 --
 drivers/mtd/mtd_blkdevs.c | 2 +-
 4 files changed, 7 insertions(+), 5 deletions(-)

-- 
1.9.1.423.g4596e3a

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/4] Limit max_discard_sectors to UINT_MAX>>9

[Gwendal Grignou]

max_discard_sectors can not be larger than UINT_MAX>>9,
otherwise, there is a risk that discard requests would be merged
into a request larger than 4GB.

Signed-off-by: Gwendal Grignou 
---
 drivers/mtd/mtd_blkdevs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/mtd_blkdevs.c b/drivers/mtd/mtd_blkdevs.c
index 5073cbc..e74090c 100644
--- a/drivers/mtd/mtd_blkdevs.c
+++ b/drivers/mtd/mtd_blkdevs.c
@@ -416,7 +416,7 @@ int add_mtd_blktrans_dev(struct mtd_blktrans_dev *new)
 
if (tr->discard) {
queue_flag_set_unlocked(QUEUE_FLAG_DISCARD, new->rq);
-   new->rq->limits.max_discard_sectors = UINT_MAX;
+   new->rq->limits.max_discard_sectors = UINT_MAX >> 9;
}
 
gd->queue = new->rq;
-- 
1.9.1.423.g4596e3a

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] Documentation/SubmittingPatches: update some dead URLs

[Mitchel Humpherys]

The links to "The perfect patch" and "NO No more huge patch
bombs..." have gone stale. Update them to some working locations.

Signed-off-by: Mitchel Humpherys 
---
 Documentation/SubmittingPatches   | 4 ++--
 Documentation/ja_JP/SubmittingPatches | 4 ++--
 Documentation/zh_CN/SubmittingPatches | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 26b1e31d5a..af80689517 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -725,7 +725,7 @@ SECTION 3 - REFERENCES
 --
 
 Andrew Morton, "The perfect patch" (tpp).
-  
+  
 
 Jeff Garzik, "Linux kernel patch submission format".
   
@@ -738,7 +738,7 @@ Greg Kroah-Hartman, "How to piss off a kernel subsystem 
maintainer".
   
 
 NO No more huge patch bombs to linux-kernel@vger.kernel.org people!
-  
+  
 
 Kernel Documentation/CodingStyle:
   
diff --git a/Documentation/ja_JP/SubmittingPatches 
b/Documentation/ja_JP/SubmittingPatches
index 97f78dd0c0..ff6cb5729c 100644
--- a/Documentation/ja_JP/SubmittingPatches
+++ b/Documentation/ja_JP/SubmittingPatches
@@ -695,7 +695,7 @@ gcc においては、マクロと同じくらい軽いです。
 --
 
 Andrew Morton, "The perfect patch" (tpp).
-  
+  
 
 Jeff Garzik, "Linux kernel patch submission format".
   
@@ -707,7 +707,7 @@ Greg Kroah-Hartman, "How to piss off a kernel subsystem 
maintainer".
   
 
 NO No more huge patch bombs to linux-kernel@vger.kernel.org people!
-  
+  
 
 Kernel Documentation/CodingStyle:
   
diff --git a/Documentation/zh_CN/SubmittingPatches 
b/Documentation/zh_CN/SubmittingPatches
index be0bd47250..788ab47303 100644
--- a/Documentation/zh_CN/SubmittingPatches
+++ b/Documentation/zh_CN/SubmittingPatches
@@ -394,7 +394,7 @@ Static inline 函数相比宏来说，是好得多的选择。Static inline 函
 
 
 Andrew Morton, "The perfect patch" (tpp).
-  
+  
 
 Jeff Garzik, "Linux kernel patch submission format".
   
@@ -406,7 +406,7 @@ Greg Kroah-Hartman, "How to piss off a kernel subsystem 
maintainer".
   
 
 NO No more huge patch bombs to linux-kernel@vger.kernel.org people!
-  
+  
 
 Kernel Documentation/CodingStyle:
   
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] Documentation/SubmittingPatches: remove references to patch-scripts

[Mitchel Humpherys]

The link to the tarball for Andrew Morton's patch scripts is dead. These
scripts don't seem to be used for kernel development these days anyways
so just rip out all references to them.

Signed-off-by: Mitchel Humpherys 
---
 Documentation/SubmittingPatches   | 5 -
 Documentation/ja_JP/SubmittingPatches | 5 -
 Documentation/zh_CN/SubmittingPatches | 4 
 3 files changed, 14 deletions(-)

diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index af80689517..3294469efd 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -75,11 +75,6 @@ There are a number of scripts which can aid in this:
 Quilt:
 http://savannah.nongnu.org/projects/quilt
 
-Andrew Morton's patch scripts:
-http://userweb.kernel.org/~akpm/stuff/patch-scripts.tar.gz
-Instead of these scripts, quilt is the recommended patch management
-tool (see above).
-
 
 
 2) Describe your changes.
diff --git a/Documentation/ja_JP/SubmittingPatches 
b/Documentation/ja_JP/SubmittingPatches
index ff6cb5729c..5d6ae639bf 100644
--- a/Documentation/ja_JP/SubmittingPatches
+++ b/Documentation/ja_JP/SubmittingPatches
@@ -98,11 +98,6 @@ dontdiff ファイルには Linux カーネルのビルドプロセスの過程
 Quilt:
 http://savannah.nongnu.org/projects/quilt
 
-Andrew Morton's patch scripts:
-http://userweb.kernel.org/~akpm/stuff/patch-scripts.tar.gz
-このリンクの先のスクリプトの代わりとして、quilt がパッチマネジメント
-ツールとして推奨されています(上のリンクを見てください)。
-
 2) パッチに対する説明
 
 パッチの中の変更点に対する技術的な詳細について説明してください。
diff --git a/Documentation/zh_CN/SubmittingPatches 
b/Documentation/zh_CN/SubmittingPatches
index 788ab47303..1d3a10f874 100644
--- a/Documentation/zh_CN/SubmittingPatches
+++ b/Documentation/zh_CN/SubmittingPatches
@@ -82,10 +82,6 @@ Documentation/SubmittingDrivers 。
 Quilt:
 http://savannah.nongnu.org/projects/quilt
 
-Andrew Morton 的补丁脚本:
-http://userweb.kernel.org/~akpm/stuff/patch-scripts.tar.gz
-作为这些脚本的替代，quilt 是值得推荐的补丁管理工具(看上面的链接)。
-
 2)描述你的改动。
 描述你的改动包含的技术细节。
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/2] URL cleanup in Documentation/SubmittingPatches

[Mitchel Humpherys]

Some URLs in Documentation/SubmittingPatches have gone stale. This
series cleans some of them up by removing or updating them.

Mitchel Humpherys (2):
  Documentation/SubmittingPatches: update some dead URLs
  Documentation/SubmittingPatches: remove references to patch-scripts

 Documentation/SubmittingPatches   | 9 ++---
 Documentation/ja_JP/SubmittingPatches | 9 ++---
 Documentation/zh_CN/SubmittingPatches | 8 ++--
 3 files changed, 6 insertions(+), 20 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/4] Limit max_discard_sectors to UINT_MAX>>9

[Gwendal Grignou]

max_discard_sectors can not be larger than UINT_MAX>>9,
otherwise, there is a risk that discard requests would be merged
into a request larger than 4GB.

Signed-off-by: Gwendal Grignou 
---
 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 2dc3b51..f30128b 100644
--- a/drivers/block/nbd.c
+++ b/drivers/block/nbd.c
@@ -859,7 +859,7 @@ static int __init nbd_init(void)
 */
queue_flag_set_unlocked(QUEUE_FLAG_NONROT, disk->queue);
disk->queue->limits.discard_granularity = 512;
-   disk->queue->limits.max_discard_sectors = UINT_MAX;
+   disk->queue->limits.max_discard_sectors = UINT_MAX >> 9;
disk->queue->limits.discard_zeroes_data = 0;
blk_queue_max_hw_sectors(disk->queue, 65536);
disk->queue->limits.max_sectors = 256;
-- 
1.9.1.423.g4596e3a

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/4] Limit max_discard_sectors to UINT_MAX>>9

[Gwendal Grignou]

max_discard_sectors can not be larger than UINT_MAX>>9,
otherwise, there is a risk that discard requests would be merged
into a request larger than 4GB.

Signed-off-by: Gwendal Grignou 
---
 block/blk-lib.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/block/blk-lib.c b/block/blk-lib.c
index 9b5b561..67bb0e7 100644
--- a/block/blk-lib.c
+++ b/block/blk-lib.c
@@ -64,7 +64,7 @@ int blkdev_issue_discard(struct block_device *bdev, sector_t 
sector,
 * Ensure that max_discard_sectors is of the proper
 * granularity, so that requests stay aligned after a split.
 */
-   max_discard_sectors = min(q->limits.max_discard_sectors, UINT_MAX >> 9);
+   max_discard_sectors = q->limits.max_discard_sectors;
max_discard_sectors -= max_discard_sectors % granularity;
if (unlikely(!max_discard_sectors)) {
/* Avoid infinite loop below. Being cautious never hurts. */
-- 
1.9.1.423.g4596e3a

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/4] Limit max_discard_sectors to UINT_MAX>>9

[Gwendal Grignou]

max_discard_sectors can not be larger than UINT_MAX>>9,
otherwise, there is a risk that discard requests would be merged
into a request larger than 4GB.
Ensure that max_discard_sectors is in unit of sectors.

Signed-off-by: Gwendal Grignou 
---
 drivers/mmc/core/core.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index 57a2b40..46e7ced 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2153,7 +2153,7 @@ static unsigned int mmc_do_calc_max_discard(struct 
mmc_card *card,
if (qty == 1)
return 1;
 
-   /* Convert qty to sectors */
+   /* Convert qty to bytes */
if (card->erase_shift)
max_discard = --qty << card->erase_shift;
else if (mmc_card_sd(card))
@@ -2170,7 +2170,7 @@ unsigned int mmc_calc_max_discard(struct mmc_card *card)
unsigned int max_discard, max_trim;
 
if (!host->max_discard_to)
-   return UINT_MAX;
+   return UINT_MAX >> 9;
 
/*
 * Without erase_group_def set, MMC erase timeout depends on clock
@@ -2188,6 +2188,8 @@ unsigned int mmc_calc_max_discard(struct mmc_card *card)
} else if (max_discard < card->erase_size) {
max_discard = 0;
}
+   /* convert max_discard to sectors */
+   max_discard >>= 9;
pr_debug("%s: calculated max. discard sectors %u for timeout %u ms\n",
 mmc_hostname(host), max_discard, host->max_discard_to);
return max_discard;
-- 
1.9.1.423.g4596e3a

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 2/2] ARM hibernation / suspend-to-disk

[Alexander Holler]

Am 25.03.2014 19:38, schrieb Alexander Holler:


reboot too. Another solution would be to unregister the reboot_notifier
in the reboot_nofifier itself. I've just seen one watchdog driver
(drivers/rtc/rtc-m41t80.c) which does that. But I still think such


That, btw. is broken. ;)

Right after having send the mail, I've became that intuition, had a look 
and ... notifier.h does state the following:


 * atomic_notifier_chain_unregister(), 
blocking_notifier_chain_unregister(),

 * and srcu_notifier_chain_unregister() _must not_ be called from within
 * the call chain.

(The reboot-notifier chain is of type blocking_notifier_chain)

So I've picked up one user of reboot_notifier by random and had the luck 
to choose a broken one. ;)


I will make a patch and will have a look if the same failure can be 
found elsewhere. There aren't that much users of the reboot-notifier, so 
it shouldn't cost me that much time.


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: [PATCH] Fix late crypto work queue initialization

[Tim Chen]

On Fri, 2014-03-21 at 22:40 +0800, Herbert Xu wrote:
> On Mon, Mar 17, 2014 at 04:52:26PM -0700, Tim Chen wrote:
> > The crypto algorithm modules utilizing the crypto daemon could
> > be used early when the system start up.  Using module_init
> > does not guarantee that the daemon's work queue is initialized
> > when the cypto alorithm depending on crypto_wq starts.  It is necessary
> > to initialize the crypto work queue earlier at the subsystem
> > init time to make sure that it is initialized
> > when used.
> > 
> > Signed-off-by: Tim Chen 
> 
> Patch applied.

Herbert,

Probably this patch should go to the stable patches as well.
Copying Greg.

Thanks.

Tim

--
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] Pre-emption control for userspace

[Khalid Aziz]

On 03/25/2014 05:01 PM, Davidlohr Bueso wrote:

Good timing! The topic came up just yesterday in LSF/MM. This
functionality is on the wish list for both facebook and postgres.



Thanks for letting me know. I am glad to hear of others who need this 
functionality. Did you happen to catch the names of folks at facebook 
and postgres that are interested in this? I would like to work with them 
to make sure what I do works for them as well.


--
Khalid
--
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] x86: Don't rebuild 32-bit vdsos on every make

[Andy Lutomirski]

vdso32/vclock_gettime.o was confusing kbuild.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/vdso/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/vdso/Makefile b/arch/x86/vdso/Makefile
index a2de5fc..6e6361a 100644
--- a/arch/x86/vdso/Makefile
+++ b/arch/x86/vdso/Makefile
@@ -136,7 +136,7 @@ override obj-dirs = $(dir $(obj)) $(obj)/vdso32/
 
 targets += vdso32/vdso32.lds
 targets += $(vdso32-images) $(vdso32-images:=.dbg)
-targets += vdso32/note.o $(vdso32.so-y:%=vdso32/%.o)
+targets += vdso32/note.o vdso32/vclock_gettime.o $(vdso32.so-y:%=vdso32/%.o)
 
 extra-y+= $(vdso32-images)
 
-- 
1.8.5.3

--
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/