details required

i have a business proposal for you with urgent transfer notice please send me 
reply to maekhalsa...@gmail.com or my official email sa...@iraqrepvp.comze.com 
with your
contact details and personal mobile number if you are interested.

you can also call me at my direct sattelite number +447937455418 for detailed 
discussion

regards
maekhal salem

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

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

Re: [PATCH v2 2/4] ocfs2: sysfile interfaces for online file check

[Gang He]

Hi Junxiao,

Thank for your reviewing.
Current design, we use a sysfile as a interface to check/fix a file (via pass a 
ino number).
But, this operation is manually triggered by user, instead of automatically  
fix in the kernel.
Why?
1) we should let users make this decision, since some users do not want to fix 
when encountering a file system corruption, maybe they want to keep the file 
system unchanged for a further investigation.
2) frankly speaking, this feature will probably bring a second corruption if 
there is some error in the code, I do not suggest to use automatically fix by 
default in the first version.
3) in the future, if this feature is well proved, we can add a mount option to 
make this automatically fix enabled.


Thanks
Gang
   


>>> 
> Hi Gang,
> 
> I didn't see a need to add a sysfs file for the check and repair. This
> leaves a hard problem for customer to decide. How they decide whether
> they should repair the bad inode since this may cause corruption even
> harder?
> I think the error should be fixed by this feature automaticlly if repair
> helps, of course this can be done only when error=continue is enabled or
> add some mount option for it.
> 
> Thanks,
> Junxiao.
> 
> On 10/28/2015 02:25 PM, Gang He wrote:
>> Implement online file check sysfile interfaces, e.g.
>> how to create the related sysfile according to device name,
>> how to display/handle file check request from the sysfile.
>> 
>> Signed-off-by: Gang He 
>> ---
>>  fs/ocfs2/Makefile|   3 +-
>>  fs/ocfs2/filecheck.c | 566 
> +++
>>  fs/ocfs2/filecheck.h |  48 +
>>  fs/ocfs2/inode.h |   3 +
>>  4 files changed, 619 insertions(+), 1 deletion(-)
>>  create mode 100644 fs/ocfs2/filecheck.c
>>  create mode 100644 fs/ocfs2/filecheck.h
>> 
>> diff --git a/fs/ocfs2/Makefile b/fs/ocfs2/Makefile
>> index ce210d4..e27e652 100644
>> --- a/fs/ocfs2/Makefile
>> +++ b/fs/ocfs2/Makefile
>> @@ -41,7 +41,8 @@ ocfs2-objs := \
>>  quota_local.o   \
>>  quota_global.o  \
>>  xattr.o \
>> -acl.o
>> +acl.o   \
>> +filecheck.o
>>  
>>  ocfs2_stackglue-objs := stackglue.o
>>  ocfs2_stack_o2cb-objs := stack_o2cb.o
>> diff --git a/fs/ocfs2/filecheck.c b/fs/ocfs2/filecheck.c
>> new file mode 100644
>> index 000..f12ed1f
>> --- /dev/null
>> +++ b/fs/ocfs2/filecheck.c
>> @@ -0,0 +1,566 @@
>> +/* -*- mode: c; c-basic-offset: 8; -*-
>> + * vim: noexpandtab sw=8 ts=8 sts=0:
>> + *
>> + * filecheck.c
>> + *
>> + * Code which implements online file check.
>> + *
>> + * Copyright (C) 2015 Novell.  All rights reserved.
>> + *
>> + * 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.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>> + * General Public License for more details.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "ocfs2.h"
>> +#include "ocfs2_fs.h"
>> +#include "stackglue.h"
>> +#include "inode.h"
>> +
>> +#include "filecheck.h"
>> +
>> +
>> +/* File check error strings,
>> + * must correspond with error number in header file.
>> + */
>> +static const char * const ocfs2_filecheck_errs[] = {
>> +"SUCCESS",
>> +"FAILED",
>> +"INPROGRESS",
>> +"READONLY",
>> +"INVALIDINO",
>> +"BLOCKECC",
>> +"BLOCKNO",
>> +"VALIDFLAG",
>> +"GENERATION",
>> +"UNSUPPORTED"
>> +};
>> +
>> +static DEFINE_SPINLOCK(ocfs2_filecheck_sysfs_lock);
>> +static LIST_HEAD(ocfs2_filecheck_sysfs_list);
>> +
>> +struct ocfs2_filecheck {
>> +struct list_head fc_head;   /* File check entry list head */
>> +spinlock_t fc_lock;
>> +unsigned int fc_max;/* Maximum number of entry in list */
>> +unsigned int fc_size;   /* Current entry count in list */
>> +unsigned int fc_done;   /* File check entries are done in list */
>> +};
>> +
>> +struct ocfs2_filecheck_sysfs_entry {
>> +struct list_head fs_list;
>> +atomic_t fs_count;
>> +struct super_block *fs_sb;
>> +struct kset *fs_kset;
>> +struct ocfs2_filecheck *fs_fcheck;
>> +};
>> +
>> +#define OCFS2_FILECHECK_MAXSIZE 100
>> +#define OCFS2_FILECHECK_MINSIZE 10
>> +
>> +/* File check operation type */
>> +enum {
>> +OCFS2_FILECHECK_TYPE_CHK = 0,   /* Check a file */
>> +OCFS2_FILECHECK_TYPE_FIX,   /* Fix a file */
>> +OCFS2_FILECHECK_TYPE_SET = 100  /* Set file check options */
>> +};
>> +
>> +struct ocfs2_filecheck_entry {
>> +struct list_head fe_list;
>> +unsigned long fe_ino;
>> +unsigned int fe_type;
>> +unsigned short fe_done:1;
>> +unsig

[PATCH net] ipv6: fix tunnel error handling

[Michal Kubecek]

Both tunnel6_protocol and tunnel46_protocol share the same error
handler, tunnel6_err(), which traverses through tunnel6_handlers list.
For ipip6 tunnels, we need to traverse tunnel46_handlers as we do e.g.
in tunnel46_rcv(). Current code can generate an ICMPv6 error message
with an IPv4 packet embedded in it.

Fixes: 73d605d1abbd ("[IPSEC]: changing API of xfrm6_tunnel_register")
Signed-off-by: Michal Kubecek 
---
 net/ipv6/tunnel6.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/net/ipv6/tunnel6.c b/net/ipv6/tunnel6.c
index 3c758007b327..dae25cad05cd 100644
--- a/net/ipv6/tunnel6.c
+++ b/net/ipv6/tunnel6.c
@@ -144,6 +144,16 @@ static void tunnel6_err(struct sk_buff *skb, struct 
inet6_skb_parm *opt,
break;
 }
 
+static void tunnel46_err(struct sk_buff *skb, struct inet6_skb_parm *opt,
+u8 type, u8 code, int offset, __be32 info)
+{
+   struct xfrm6_tunnel *handler;
+
+   for_each_tunnel_rcu(tunnel46_handlers, handler)
+   if (!handler->err_handler(skb, opt, type, code, offset, info))
+   break;
+}
+
 static const struct inet6_protocol tunnel6_protocol = {
.handler= tunnel6_rcv,
.err_handler= tunnel6_err,
@@ -152,7 +162,7 @@ static const struct inet6_protocol tunnel6_protocol = {
 
 static const struct inet6_protocol tunnel46_protocol = {
.handler= tunnel46_rcv,
-   .err_handler= tunnel6_err,
+   .err_handler= tunnel46_err,
.flags  = INET6_PROTO_NOPOLICY|INET6_PROTO_FINAL,
 };
 
-- 
2.6.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: linux-next: build failure after merge of the pci tree

[Ley Foon Tan]

On Isn, 2015-11-02 at 12:12 -0600, Bjorn Helgaas wrote:
> On Sun, Nov 1, 2015 at 6:00 PM, Ley Foon Tan  wrote:
> > On Isn, 2015-11-02 at 02:23 +1100, Stephen Rothwell wrote:
> >> Hi Bjorn,
> >>
> >> After merging the pci tree, today's linux-next build (powerpc
> >> allyesconfig) failed like this:
> >>
> >> In file included from include/linux/kvm_host.h:20:0,
> >>  from arch/powerpc/kernel/asm-offsets.c:54:
> >> include/linux/msi.h:174:21: fatal error: asm/msi.h: No such file or 
> >> directory
> >>
> >> Caused by commit
> >>
> >>   f19eafec930f ("PCI: altera: Add Altera PCIe MSI driver")
> >>
> >> I have disabled that driver for today:
> >>
> >> From: Stephen Rothwell 
> >> Date: Mon, 2 Nov 2015 02:12:54 +1100
> >> Subject: [PATCH] PCI: altera: disable MSI driver for now
> >>
> >> Signed-off-by: Stephen Rothwell 
> >> ---
> >>  drivers/pci/host/Kconfig | 1 +
> >>  1 file changed, 1 insertion(+)
> >>
> >> diff --git a/drivers/pci/host/Kconfig b/drivers/pci/host/Kconfig
> >> index 2af0571356e8..7a31ebbc4379 100644
> >> --- a/drivers/pci/host/Kconfig
> >> +++ b/drivers/pci/host/Kconfig
> >> @@ -158,6 +158,7 @@ config PCIE_ALTERA
> >>  config PCIE_ALTERA_MSI
> >>   bool "Altera PCIe MSI feature"
> >>   depends on PCI_MSI
> >> + depends on BROKEN
> >>   select PCI_MSI_IRQ_DOMAIN
> >>   help
> >> Say Y here if you want PCIe MSI support for the Altera FPGA.
> >> --
> >> 2.6.1
> >>
> > Hi Bjorn
> >
> > This driver depends on the asm/msi.h and not all architectures include
> > the asm/msi.h.
> > We can fix this by adding "depends on ARM || NIOS2" to Kconfig, same as
> > altera pcie driver. What do you think?
> 
> I don't think your driver depends on asm/msi.h because ARM doesn't
> have asm/msi.h either.
> 
> I think the best thing is to do this:
> 
> config PCIE_ALTERA_MSI
> bool "Altera PCIe MSI feature"
> depends on PCIE_ALTERA && PCI_MSI
> 
> That way we don't have to repeat the constraints from PCIE_ALTERA.
> This is the same strategy used by PCI_XGENE & PCI_XGENE_MSI.
> 
Okay. Thanks for the fix.

Regards
Ley Foon

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] perf sched latency: Fix removed thread issue

[Jiri Olsa]

On Tue, Nov 03, 2015 at 07:27:21AM +0900, Namhyung Kim wrote:
> On Mon, Nov 02, 2015 at 12:10:25PM +0100, Jiri Olsa wrote:
> > If machine's thread gets excited (EXIT event is received),
> 
> Why a thread get *excited* when it received EXIT event? :)

wouldn't you? I would.. ;-)

jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [net-next v4 2/8] dpaa_eth: add support for DPAA Ethernet

[Joakim Tjernlund]

On Mon, 2015-11-02 at 19:31 +0200, Madalin Bucur wrote:
> +   if (unlikely(fd_status & FM_FD_STAT_RX_ERRORS) != 0) {
> +   if (net_ratelimit())
> +   netif_warn(priv, hw, net_dev, "FD status = 0x%08x\n",
> +  fd_status & FM_FD_STAT_RX_ERRORS);
> +
> +   percpu_stats->rx_errors++;
> +   goto _release_frame;
> +   }

I cannot find any detailed error accounting(maybe I am not looking hard enough) 
but I
would appreciate if both TX and RX errors where better 
accounted(rx_length_errors, rx_frame_errors,
rx_crc_errors, rx_fifo_errors etc.). This has helped me many times in the past 
diagnosing
board HW problems.

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

Re: [PATCH v2 2/2] watchdog: imx2_wdt: add set_pretimeout interface

[Robin Gong]

On Mon, Nov 02, 2015 at 11:48:29PM -0800, Guenter Roeck wrote:
> On 11/02/2015 10:11 PM, Robin Gong wrote:
> >Enable set_pretimeout interface and trigger the pretimeout interrupt before
> >watchdog timeout event happen.
> >
> >Signed-off-by: Robin Gong 
> >---
> >  drivers/watchdog/imx2_wdt.c | 58 
> > -
> >  1 file changed, 57 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
> >index 0bb1a1d..bd42857 100644
> >--- a/drivers/watchdog/imx2_wdt.c
> >+++ b/drivers/watchdog/imx2_wdt.c
> >@@ -24,6 +24,7 @@
> >  #include 
> >  #include 
> >  #include 
> >+#include 
> >  #include 
> >  #include 
> >  #include 
> >@@ -52,12 +53,18 @@
> >  #define IMX2_WDT_WRSR  0x04/* Reset Status 
> > Register */
> >  #define IMX2_WDT_WRSR_TOUT (1 << 1)/* -> Reset due to Timeout */
> >
> >+#define IMX2_WDT_WICR   0x06/*Interrupt Control 
> >Register*/
> >+#define IMX2_WDT_WICR_WIE   (1 << 15)   /* -> Interrupt Enable */
> >+#define IMX2_WDT_WICR_WTIS  (1 << 14)   /* -> Interrupt Status */
> >+#define IMX2_WDT_WICR_WICT  (0xFF)  /* Watchdog Interrupt Timeout */
> 
> Unnecessary ( )
> 
> >+
> >  #define IMX2_WDT_WMCR  0x08/* Misc Register */
> >
> >  #define IMX2_WDT_MAX_TIME  128
> >  #define IMX2_WDT_DEFAULT_TIME  60  /* in seconds */
> >
> >  #define WDOG_SEC_TO_COUNT(s)   ((s * 2 - 1) << 8)
> >+#define WDOG_SEC_TO_PRECOUNT(s) ((s) * 2)   /* set WDOG pre timeout 
> >count*/
> >
> >  struct imx2_wdt_device {
> > struct clk *clk;
> >@@ -80,7 +87,8 @@ MODULE_PARM_DESC(timeout, "Watchdog timeout in seconds 
> >(default="
> >
> >  static const struct watchdog_info imx2_wdt_info = {
> > .identity = "imx2+ watchdog",
> >-.options = WDIOF_KEEPALIVEPING | WDIOF_SETTIMEOUT | WDIOF_MAGICCLOSE,
> >+.options = WDIOF_KEEPALIVEPING | WDIOF_SETTIMEOUT | WDIOF_MAGICCLOSE
> >+   | WDIOF_PRETIMEOUT,
> >  };
> >
> >  static int imx2_restart_handler(struct notifier_block *this, unsigned long 
> > mode,
> >@@ -207,12 +215,49 @@ static inline void imx2_wdt_ping_if_active(struct 
> >watchdog_device *wdog)
> > }
> >  }
> >
> >+static int imx2_wdt_set_pretimeout(struct watchdog_device *wdog,
> >+   unsigned int new_timeout)
> >+{
> >+struct imx2_wdt_device *wdev = watchdog_get_drvdata(wdog);
> >+u32 val;
> >+
> >+regmap_read(wdev->regmap, IMX2_WDT_WICR, &val);
> >+/* set the new pre-timeout value in the WSR */
> >+val &= ~IMX2_WDT_WICR_WICT;
> >+val |= WDOG_SEC_TO_PRECOUNT(new_timeout);
> 
> Looking into this, I think we need more information in the first patch.
> Specifically, we need a value for max_pretimeout and validate it
> (new_timeout must be smaller than 128 to avoid overflows, independent
> of the maximum timeout).
>
I think it's enough, since there is "t >= wdd->timeout" in
watchdog_pretimeout_invalid() of the first patch and wdd->timeout is never
bigger than wdd->max_timeout which setting in imx2_wdt.c as 128.
> >+
> >+regmap_write(wdev->regmap, IMX2_WDT_WICR, val | IMX2_WDT_WICR_WIE);
> >+
> >+wdog->pretimeout = new_timeout;
> >+
> >+return 0;
> >+}
> >+
> >+static irqreturn_t imx2_wdt_isr(int irq, void *dev_id)
> >+{
> >+struct platform_device *pdev = dev_id;
> >+struct watchdog_device *wdog = platform_get_drvdata(pdev);
> >+struct imx2_wdt_device *wdev = watchdog_get_drvdata(wdog);
> >+u32 val;
> >+
> >+regmap_read(wdev->regmap, IMX2_WDT_WICR, &val);
> >+if (val & IMX2_WDT_WICR_WTIS) {
> >+/*clear interrupt status bit*/
> >+regmap_write(wdev->regmap, IMX2_WDT_WICR, val);
> >+panic("pre-timeout:%d, %d Seconds remained\n", wdog->pretimeout,
> 
> "seconds" - no capital 'S'.
> 
> >+  wdog->timeout - wdog->pretimeout);
> >+}
> >+
> >+return IRQ_HANDLED;
> >+}
> >+
> >  static const struct watchdog_ops imx2_wdt_ops = {
> > .owner = THIS_MODULE,
> > .start = imx2_wdt_start,
> > .stop = imx2_wdt_stop,
> > .ping = imx2_wdt_ping,
> > .set_timeout = imx2_wdt_set_timeout,
> >+.set_pretimeout = imx2_wdt_set_pretimeout,
> >  };
> >
> >  static const struct regmap_config imx2_wdt_regmap_config = {
> >@@ -229,6 +274,7 @@ static int __init imx2_wdt_probe(struct platform_device 
> >*pdev)
> > struct resource *res;
> > void __iomem *base;
> > int ret;
> >+int irq;
> > u32 val;
> >
> > wdev = devm_kzalloc(&pdev->dev, sizeof(*wdev), GFP_KERNEL);
> >@@ -294,6 +340,16 @@ static int __init imx2_wdt_probe(struct platform_device 
> >*pdev)
> > goto disable_clk;
> > }
> >
> >+irq = platform_get_irq(pdev, 0);
> >+if (irq > 0) {
> >+ret = devm_request_irq(&pdev->dev, irq, imx2_wdt_isr, 0,
> >+   dev_name(&pdev->dev), pdev);
> >+if (ret) {
> >+ 

Re: [lkp] [x86/setup] f5f3497cad: BUG: kernel boot crashed

[Ingo Molnar]

* Matt Fleming  wrote:

> On Wed, 28 Oct, at 01:41:51PM, kernel test robot wrote:
> > FYI, we noticed the below changes on
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
> > commit f5f3497cad8c8416a74b9aaceb127908755d020a ("x86/setup: Extend low 
> > identity map to cover whole kernel range")
> > 
> > 
> > ++++
> > || 8a53554e12 | f5f3497cad |
> > ++++
> > | boot_successes | 19 | 10 |
> > | boot_failures  | 2  | 9  |
> > | IP-Config:Auto-configuration_of_network_failed | 2  | 2  |
> > | BUG:kernel_boot_crashed| 0  | 7  |
> > ++++
> > 
> > 
> > [0.053410] smpboot: CPU0: GenuineIntel GenuineIntel QEMU Virtual CPU 
> > version 2.4.0QEMU Virtual CPU version 2.4.0 (family: 0x6, model: 0x6 
> > (family: 0x6, model: 0x6, stepping: 0x3)
> > , stepping: 0x3)
> > [0.05] Performance Events: 
> > [0.05] Performance Events: no PMU driver, software events only.
> > no PMU driver, software events only.
> > [0.060520] CPU 1 irqstacks, hard=8a832000 soft=8a834000
> > [0.060520] CPU 1 irqstacks, hard=8a832000 soft=8a834000
> > [0.061605] x86: Booting SMP configuration:
> > [0.061605] x86: Booting SMP configuration:
> > [0.062445]  node  #0, CPUs:  
> > [0.062445]  node  #0, CPUs: #1 #1
> > Elapsed time: 10
> > BUG: kernel boot crashed
> 
> Yikes! Yeah, I can reproduce this. It appears the STARTUP IPI code is
> triggering this crash in wakeup_secondary_cpu_via_init().
> 
> I'll take a look unless anyone else has any bright ideas?

Unfortunately this commit is now part of the v4.3 kernel, so we need a quick 
solution or a quick revert.

Thanks,

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

[PATCH v2 10/12] usb: xhci: dbc: add handshake between debug target and host

[Lu Baolu]

After DbC setup, debug target needs to wait until tty driver and
application (e.g. mincom) on debug taget start.  Otherwise, out
messages might be ignored.

This patch adds a ping/pong mechanism between debug target and
host. Debug target will be waiting there until user presses 'Y'
or 'y' in the tty application.

Signed-off-by: Lu Baolu 
---
 drivers/usb/early/xhci-dbc.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index 68a7139..b75c523 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -32,6 +32,9 @@
 static struct xdbc_state xdbc_stat;
 static struct xdbc_state *xdbcp = &xdbc_stat;
 
+static int early_xdbc_read(struct console *con, char *str, unsigned n);
+static void early_xdbc_write(struct console *con, const char *str, u32 n);
+
 #ifdef DBC_DEBUG
 #defineXDBC_DEBUG_BUF_SIZE (PAGE_SIZE * 32)
 #defineMSG_MAX_LINE128
@@ -873,8 +876,12 @@ int __init early_xdbc_init(char *s)
 {
u32 bus = 0, dev = 0, func = 0;
unsigned long dbgp_num = 0;
+   char *ping = "Press Y to continue...\n";
+   char pong[64];
+   size_t size;
u32 offset;
int ret;
+   int retry = 20;
 
if (!early_pci_allowed())
return -EPERM;
@@ -917,6 +924,21 @@ int __init early_xdbc_init(char *s)
return ret;
}
 
+   while (retry > 0) {
+   early_xdbc_write(NULL, ping, strlen(ping));
+   size = early_xdbc_read(NULL, pong, 64);
+   if (size > 0) {
+   xdbc_trace("%s: pong message: %s\n", __func__, pong);
+   if (pong[0] == 'Y' || pong[0] == 'y')
+   break;
+   } else {
+   xdbc_trace("%s: pong message error %d\n",
+   __func__, size);
+   }
+
+   retry--;
+   }
+
return 0;
 }
 
@@ -1338,6 +1360,11 @@ int xdbc_bulk_write(const char *bytes, int size)
  * Start a bulk-in or bulk-out transfer, wait until transfer completion
  * or error. Return the count of actually transferred bytes or error.
  */
+static int early_xdbc_read(struct console *con, char *str, unsigned n)
+{
+   return xdbc_bulk_read(str, n, 0);
+}
+
 static void early_xdbc_write(struct console *con, const char *str, u32 n)
 {
int chunk, ret;
-- 
2.1.4

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

[PATCH v2 08/12] usb: xhci: dbc: handle endpoint stall

[Lu Baolu]

In case of endpoint stall, software is able to detect the situation
by reading DCCTRL.HIT or DCCTRL.HOT bits. DbC follows the normal USB
framework to handle endpoint stall. When software detects endpoint
stall situation, it should wait until endpoint is recovered before
read or write oprations.

Signed-off-by: Lu Baolu 
---
 drivers/usb/early/xhci-dbc.c | 36 
 1 file changed, 36 insertions(+)

diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index 8a5a51f..aaf655f 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -1176,6 +1176,37 @@ static int xdbc_wait_until_dbc_configured(void)
return -ETIMEDOUT;
 }
 
+static int xdbc_wait_until_epstall_cleared(bool read)
+{
+   int timeout = 0;
+
+   if (read) {
+   do {
+   if (!(readl(&xdbcp->xdbc_reg->control) & CTRL_HIT)) {
+   xdbcp->in_ep_state = EP_RUNNING;
+
+   return 0;
+   }
+
+   xdbcp->in_ep_state = EP_HALTED;
+   xdbc_udelay(10);
+   } while (timeout++ < XDBC_LOOPS);
+   } else {
+   do {
+   if (!(readl(&xdbcp->xdbc_reg->control) & CTRL_HOT)) {
+   xdbcp->out_ep_state = EP_RUNNING;
+
+   return 0;
+   }
+
+   xdbcp->out_ep_state = EP_HALTED;
+   xdbc_udelay(10);
+   } while (timeout++ < XDBC_LOOPS);
+   }
+
+   return -ETIMEDOUT;
+}
+
 static int xdbc_bulk_transfer(void *data, int size, int loops, bool read)
 {
u64 addr;
@@ -1195,6 +1226,11 @@ static int xdbc_bulk_transfer(void *data, int size, int 
loops, bool read)
return -EPERM;
}
 
+   if (xdbc_wait_until_epstall_cleared(read)) {
+   xdbc_trace("%s: endpoint not ready\n", __func__);
+   return -EPERM;
+   }
+
ring = (read ? &xdbcp->in_ring : &xdbcp->out_ring);
trb = ring->enqueue;
cycle = ring->cycle_state;
-- 
2.1.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/

[RESEND PATCH] ARM: errata: Workaround for Cortex-A12 erratum 818325

[Caesar Wang]

From: Huang Tao 

On Cortex-A12 (r0p0..r0p1-00lac0-rc11), when a CPU executes a sequence of
two conditional store instructions with opposite condition code and
updating the same register, the system might enter a deadlock if the
second conditional instruction is an UNPREDICTABLE STR or STM
instruction. This workaround setting bit[12] of the Feature Register
prevents the erratum. This bit disables an optimisation applied to a
sequence of 2 instructions that use opposing condition codes.

Signed-off-by: Huang Tao 
Signed-off-by: Kever Yang 
Signed-off-by: Caesar Wang 

---

 arch/arm/Kconfig  | 13 +
 arch/arm/mm/proc-v7.S | 12 
 2 files changed, 25 insertions(+)

diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 639411f..554b57a 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1263,6 +1263,19 @@ config ARM_ERRATA_773022
  loop buffer may deliver incorrect instructions. This
  workaround disables the loop buffer to avoid the erratum.
 
+config ARM_ERRATA_818325
+   bool "ARM errata: Execution of an UNPREDICTABLE STR or STM instruction 
might deadlock"
+   depends on CPU_V7
+   help
+ This option enables the workaround for the 818325 Cortex-A12
+ (r0p0..r0p1-00lac0-rc11) erratum. When a CPU executes a sequence of
+ two conditional store instructions with opposite condition code and
+ updating the same register, the system might enter a deadlock if the
+ second conditional instruction is an UNPREDICTABLE STR or STM
+ instruction. This workaround setting bit[12] of the Feature Register
+ prevents the erratum. This bit disables an optimisation applied to a
+ sequence of 2 instructions that use opposing condition codes.
+
 endmenu
 
 source "arch/arm/common/Kconfig"
diff --git a/arch/arm/mm/proc-v7.S b/arch/arm/mm/proc-v7.S
index de2b246..2b338ec 100644
--- a/arch/arm/mm/proc-v7.S
+++ b/arch/arm/mm/proc-v7.S
@@ -439,6 +439,18 @@ __v7_setup_cont:
teq r0, r10
beq __ca9_errata
 
+   /* Cortex-A12 Errata */
+   ldr r10, =0x0c0d@ Cortex-A12 primary part number
+   teq r0, r10
+   bne 5f
+#ifdef CONFIG_ARM_ERRATA_818325
+   teq r6, #0x00   @ present in r0p0
+   teqne   r6, #0x01   @ present in r0p1-00lac0-rc11
+   mrceq   p15, 0, r10, c15, c0, 1 @ read diagnostic register
+   orreq   r10, r10, #1 << 12  @ set bit #12
+   mcreq   p15, 0, r10, c15, c0, 1 @ write diagnostic register
+   isb
+#endif
/* Cortex-A15 Errata */
ldr r10, =0x0c0f@ Cortex-A15 primary part number
teq r0, r10
-- 
1.9.1

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

Re: [PATCH v2 2/4] ocfs2: sysfile interfaces for online file check

[Junxiao Bi]

Hi Gang,

On 11/03/2015 03:54 PM, Gang He wrote:
> Hi Junxiao,
> 
> Thank for your reviewing.
> Current design, we use a sysfile as a interface to check/fix a file (via pass 
> a ino number).
> But, this operation is manually triggered by user, instead of automatically  
> fix in the kernel.
> Why?
> 1) we should let users make this decision, since some users do not want to 
> fix when encountering a file system corruption, maybe they want to keep the 
> file system unchanged for a further investigation.
If user don't want this, they should not use error=continue option, let
fs go after a corruption is very dangerous.
> 2) frankly speaking, this feature will probably bring a second corruption if 
> there is some error in the code, I do not suggest to use automatically fix by 
> default in the first version.
I think if this feature could bring more corruption, then this should be
fixed first.

Thanks,
Junxiao
> 3) in the future, if this feature is well proved, we can add a mount option 
> to make this automatically fix enabled.
> 
> 
> Thanks
> Gang
>
> 
> 

>> Hi Gang,
>>
>> I didn't see a need to add a sysfs file for the check and repair. This
>> leaves a hard problem for customer to decide. How they decide whether
>> they should repair the bad inode since this may cause corruption even
>> harder?
>> I think the error should be fixed by this feature automaticlly if repair
>> helps, of course this can be done only when error=continue is enabled or
>> add some mount option for it.
>>
>> Thanks,
>> Junxiao.
>>
>> On 10/28/2015 02:25 PM, Gang He wrote:
>>> Implement online file check sysfile interfaces, e.g.
>>> how to create the related sysfile according to device name,
>>> how to display/handle file check request from the sysfile.
>>>
>>> Signed-off-by: Gang He 
>>> ---
>>>  fs/ocfs2/Makefile|   3 +-
>>>  fs/ocfs2/filecheck.c | 566 
>> +++
>>>  fs/ocfs2/filecheck.h |  48 +
>>>  fs/ocfs2/inode.h |   3 +
>>>  4 files changed, 619 insertions(+), 1 deletion(-)
>>>  create mode 100644 fs/ocfs2/filecheck.c
>>>  create mode 100644 fs/ocfs2/filecheck.h
>>>
>>> diff --git a/fs/ocfs2/Makefile b/fs/ocfs2/Makefile
>>> index ce210d4..e27e652 100644
>>> --- a/fs/ocfs2/Makefile
>>> +++ b/fs/ocfs2/Makefile
>>> @@ -41,7 +41,8 @@ ocfs2-objs := \
>>> quota_local.o   \
>>> quota_global.o  \
>>> xattr.o \
>>> -   acl.o
>>> +   acl.o   \
>>> +   filecheck.o
>>>  
>>>  ocfs2_stackglue-objs := stackglue.o
>>>  ocfs2_stack_o2cb-objs := stack_o2cb.o
>>> diff --git a/fs/ocfs2/filecheck.c b/fs/ocfs2/filecheck.c
>>> new file mode 100644
>>> index 000..f12ed1f
>>> --- /dev/null
>>> +++ b/fs/ocfs2/filecheck.c
>>> @@ -0,0 +1,566 @@
>>> +/* -*- mode: c; c-basic-offset: 8; -*-
>>> + * vim: noexpandtab sw=8 ts=8 sts=0:
>>> + *
>>> + * filecheck.c
>>> + *
>>> + * Code which implements online file check.
>>> + *
>>> + * Copyright (C) 2015 Novell.  All rights reserved.
>>> + *
>>> + * 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.
>>> + *
>>> + * This program is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>>> + * General Public License for more details.
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#include "ocfs2.h"
>>> +#include "ocfs2_fs.h"
>>> +#include "stackglue.h"
>>> +#include "inode.h"
>>> +
>>> +#include "filecheck.h"
>>> +
>>> +
>>> +/* File check error strings,
>>> + * must correspond with error number in header file.
>>> + */
>>> +static const char * const ocfs2_filecheck_errs[] = {
>>> +   "SUCCESS",
>>> +   "FAILED",
>>> +   "INPROGRESS",
>>> +   "READONLY",
>>> +   "INVALIDINO",
>>> +   "BLOCKECC",
>>> +   "BLOCKNO",
>>> +   "VALIDFLAG",
>>> +   "GENERATION",
>>> +   "UNSUPPORTED"
>>> +};
>>> +
>>> +static DEFINE_SPINLOCK(ocfs2_filecheck_sysfs_lock);
>>> +static LIST_HEAD(ocfs2_filecheck_sysfs_list);
>>> +
>>> +struct ocfs2_filecheck {
>>> +   struct list_head fc_head;   /* File check entry list head */
>>> +   spinlock_t fc_lock;
>>> +   unsigned int fc_max;/* Maximum number of entry in list */
>>> +   unsigned int fc_size;   /* Current entry count in list */
>>> +   unsigned int fc_done;   /* File check entries are done in list */
>>> +};
>>> +
>>> +struct ocfs2_filecheck_sysfs_entry {
>>> +   struct list_head fs_list;
>>> +   atomic_t fs_count;
>>> +   struct super_block *fs_sb;
>>> +   struct kset *fs_kset;
>>> +   struct ocfs2_filecheck *fs_fcheck;
>>> +};
>>> +
>>> +#define OCFS2_FILECHECK_MAXSIZE100
>>> +#define OCFS2_FILECHECK_MINSIZE10
>>> +
>>> +/* File c

details required

i have a business proposal for you with urgent transfer notice please send me 
reply to maekhalsa...@gmail.com or my official email sa...@iraqrepvp.comze.com 
with your
contact details and personal mobile number if you are interested.

you can also call me at my direct sattelite number +447937455418 for detailed 
discussion

regards
maekhal salem

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 05/12] usb: xhci: dbc: add debug buffer

[Lu Baolu]

"printk" is not suitable for dbc debugging especially when console
is in usage. This patch adds a debug buffer in dbc driver and puts
the debug messages in this local buffer. The debug buffer could be
dumped whenever the console is not in use. This part of code will
not be visible unless DBC_DEBUG is defined.

Signed-off-by: Lu Baolu 
---
 drivers/usb/early/xhci-dbc.c | 62 ++--
 1 file changed, 60 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index 6b23f09..b36a527 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -32,8 +32,64 @@ static struct xdbc_state xdbc_stat;
 static struct xdbc_state *xdbcp = &xdbc_stat;
 
 #ifdef DBC_DEBUG
-/* place holder */
-#definexdbc_trace  printk
+#defineXDBC_DEBUG_BUF_SIZE (PAGE_SIZE * 32)
+#defineMSG_MAX_LINE128
+static char xdbc_debug_buf[XDBC_DEBUG_BUF_SIZE];
+static void xdbc_trace(const char *fmt, ...)
+{
+   int i, size;
+   va_list args;
+   static int pos;
+   char temp_buf[MSG_MAX_LINE];
+
+   if (pos >= XDBC_DEBUG_BUF_SIZE - 1)
+   return;
+
+   memset(temp_buf, 0, MSG_MAX_LINE);
+   va_start(args, fmt);
+   vsnprintf(temp_buf, MSG_MAX_LINE - 1, fmt, args);
+   va_end(args);
+
+   i = 0;
+   size = strlen(temp_buf);
+   while (i < size) {
+   xdbc_debug_buf[pos] = temp_buf[i];
+   pos++;
+   i++;
+
+   if (pos >= XDBC_DEBUG_BUF_SIZE - 1)
+   break;
+   }
+}
+
+static void xdbc_dump_debug_buffer(void)
+{
+   int index = 0;
+   int count = 0;
+   char dump_buf[MSG_MAX_LINE];
+
+   xdbc_trace("The end of DbC trace buffer\n");
+   pr_notice("DBC debug buffer:\n");
+   memset(dump_buf, 0, MSG_MAX_LINE);
+
+   while (index < XDBC_DEBUG_BUF_SIZE) {
+   if (!xdbc_debug_buf[index])
+   break;
+
+   if (xdbc_debug_buf[index] == '\n' ||
+   count >= MSG_MAX_LINE - 1) {
+   pr_notice("DBC: @%08x %s\n", index, dump_buf);
+   memset(dump_buf, 0, MSG_MAX_LINE);
+   count = 0;
+   } else {
+   dump_buf[count] = xdbc_debug_buf[index];
+   count++;
+   }
+
+   index++;
+   }
+}
+
 static void xdbc_dbg_dump_regs(char *str)
 {
if (!xdbcp->xdbc_reg) {
@@ -165,6 +221,7 @@ static void xdbc_dbg_dump_data(char *str)
 
 #else
 static inline void xdbc_trace(const char *fmt, ...) { }
+static inline void xdbc_dump_debug_buffer(void) { }
 static inline void xdbc_dbg_dump_regs(char *str) { }
 static inline void xdbc_dbg_dump_data(char *str) { }
 #endif /* DBC_DEBUG */
@@ -832,6 +889,7 @@ int __init early_xdbc_init(char *s)
pr_notice("failed to setup xHCI DbC connection\n");
xdbcp->xhci_base = NULL;
xdbcp->xdbc_reg = NULL;
+   xdbc_dump_debug_buffer();
return ret;
}
 
-- 
2.1.4

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

[PATCH v2 12/12] usb: doc: add document for xHCI DbC driver

[Lu Baolu]

Add Documentation/usb/xhci-dbc.txt. This document includes
development status and user guide for USB3 debug port.

Signed-off-by: Lu Baolu 
---
 Documentation/usb/xhci-dbc.txt | 325 +
 MAINTAINERS|   1 +
 drivers/usb/early/xhci-dbc.c   |   3 +
 3 files changed, 329 insertions(+)
 create mode 100644 Documentation/usb/xhci-dbc.txt

diff --git a/Documentation/usb/xhci-dbc.txt b/Documentation/usb/xhci-dbc.txt
new file mode 100644
index 000..441b40c
--- /dev/null
+++ b/Documentation/usb/xhci-dbc.txt
@@ -0,0 +1,325 @@
+xHCI debug capability driver
+
+ Lu Baolu 
+
+Last-updated: September 2015
+
+
+   Contents:
+   -
+   * What is xHCI DbC?
+   * Debug topologies
+   * Debug stacks
+   * Port Multiplexing
+   * Hardware initialization
+   * External reset
+   * Port reset
+   * Interrupt/DMA/Memory during early boot
+   * Endpoint STALL
+   * Debug device information
+   * How to use DbC early printk?
+   * Limitations
+
+   What is xHCI DbC?
+   -
+
+The xHCI Debugging Capability defined in section 7.6 of xHCI spec 1.1
+provides an optional functionality that enables low-level system debug
+over USB. It provides a means of connecting two systems where one system
+is a Debug Host and the other a Debug Target (System Under Test). The
+Debug Capability provides an interface that is completely independent
+of the xHCI interface. A Debug Target enumerates as a USB debug device
+to the Debug Host, allowing a Debug Host to access a Debug Target through
+the standard USB software stack.
+
+   Debug topologies
+   
+
+Multiple Debug Targets may be attached to a single Debug Host. Debug
+Targets may be connected to any downstream facing port below a Debug
+Host (i.e. anywhere in the fabric, root port or external hub puts).
+A Debug Target may only connect to a Debug Host through a Root Hub port
+of the target. That means connection of a Debug Target to a Debug Host
+through the ports of an external hub is not supported.
+
+Below is a typical connection between Debug Host and Debug target. Two
+Debug targets are connected to a single Debug host.
+
+
+ 
+|   Debug Host   |  |  Debug Target  |
+||  ||
+|xHC without DbC |  |  xHC with DbC  |
+|or DbC disabled |  | enabled|
+||  ||
+|P1|  |p2|  |P1|  |p2|
+|__|  |__|  |__|  |__|
+  || |
+  ||_|
+  |_
+|
+ ___|
+|   HUB  |  |  Debug Target  |
+||  ||
+| Superspeed hub |  |  xHC with DbC  |
+||  | enabled|
+||  ||
+|P1|  |p2|  |P1|  |p2|
+|__|  |__|  |__|  |__|
+   | |
+   |_|
+
+   Debug stacks
+   
+
+Below is a software stack diagram of both Debug Host and Debug Target.
+
+ 
+|   Debug Host   |  |  Debug Target  |
+||  ||
+|   debug App|  ||
+||  | system debug   |
+|   usb_debug|  | hooks  |
+||  ||
+|usbcore |  ||
+||  |debug capability|
+|xhci_hcd|  | driver |
+||  ||
+|xHC without DbC |  |  xHC with DbC  |
+|or DbC disabled |  | enabled|
+||  ||
+|P1|  |p2|  |P1|  |p2|
+|__|  |__|  |__|  |__|
+   | |
+   |_|
+
+
+   Port Multiplexing
+   -
+
+A debug port is always multiplexed with the first xHCI root hub port.
+Whenever debug capability is supported and enabled, and the first root
+hub port is detected to be connected to a downstream super-speed port
+of a Debug Host, the root hub port is assigned to the debug capability
+and operating i

[PATCH v2 11/12] usb: serial: usb_debug: add support for dbc debug device

[Lu Baolu]

This patch add dbc debug device support in usb_debug driver.

Signed-off-by: Lu Baolu 
---
 drivers/usb/serial/usb_debug.c | 28 +---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/serial/usb_debug.c b/drivers/usb/serial/usb_debug.c
index ca2fa5b..92f7e5c 100644
--- a/drivers/usb/serial/usb_debug.c
+++ b/drivers/usb/serial/usb_debug.c
@@ -32,7 +32,18 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x0525, 0x127a) },
{ },
 };
-MODULE_DEVICE_TABLE(usb, id_table);
+
+static const struct usb_device_id dbc_id_table[] = {
+   { USB_DEVICE(0x1d6b, 0x0004) },
+   { },
+};
+
+static const struct usb_device_id id_table_combined[] = {
+   { USB_DEVICE(0x0525, 0x127a) },
+   { USB_DEVICE(0x1d6b, 0x0004) },
+   { },
+};
+MODULE_DEVICE_TABLE(usb, id_table_combined);
 
 /* This HW really does not support a serial break, so one will be
  * emulated when ever the break state is set to true.
@@ -71,9 +82,20 @@ static struct usb_serial_driver debug_device = {
.process_read_urb = usb_debug_process_read_urb,
 };
 
+static struct usb_serial_driver dbc_device = {
+   .driver = {
+   .owner =THIS_MODULE,
+   .name = "xhci_dbc",
+   },
+   .id_table = dbc_id_table,
+   .num_ports =1,
+   .break_ctl =usb_debug_break_ctl,
+   .process_read_urb = usb_debug_process_read_urb,
+};
+
 static struct usb_serial_driver * const serial_drivers[] = {
-   &debug_device, NULL
+   &debug_device, &dbc_device, NULL
 };
 
-module_usb_serial_driver(serial_drivers, id_table);
+module_usb_serial_driver(serial_drivers, id_table_combined);
 MODULE_LICENSE("GPL");
-- 
2.1.4

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

[PATCH v3 1/2] watchdog: add WDIOC_SETPRETIMEOUT and WDIOC_GETPRETIMEOUT

[Robin Gong]

Since the watchdog common framework centrialize the IOCTL interfaces of
device driver now, the SETPRETIMEOUT and GETPRETIMEOUT need to be added
in the common code.

Signed-off-by: Robin Gong 
---
 Documentation/watchdog/watchdog-kernel-api.txt | 12 +
 drivers/watchdog/watchdog_dev.c| 37 ++
 include/linux/watchdog.h   | 11 
 3 files changed, 60 insertions(+)

diff --git a/Documentation/watchdog/watchdog-kernel-api.txt 
b/Documentation/watchdog/watchdog-kernel-api.txt
index d8b0d33..20aa841 100644
--- a/Documentation/watchdog/watchdog-kernel-api.txt
+++ b/Documentation/watchdog/watchdog-kernel-api.txt
@@ -51,6 +51,7 @@ struct watchdog_device {
const struct watchdog_ops *ops;
unsigned int bootstatus;
unsigned int timeout;
+   unsigned int pretimeout;
unsigned int min_timeout;
unsigned int max_timeout;
void *driver_data;
@@ -73,6 +74,7 @@ It contains following fields:
   additional information about the watchdog timer itself. (Like it's unique 
name)
 * ops: a pointer to the list of watchdog operations that the watchdog supports.
 * timeout: the watchdog timer's timeout value (in seconds).
+* pretimeout:  The watchdog devices pre_timeout value.
 * min_timeout: the watchdog timer's minimum timeout value (in seconds).
 * max_timeout: the watchdog timer's maximum timeout value (in seconds).
 * bootstatus: status of the device after booting (reported with watchdog
@@ -99,6 +101,7 @@ struct watchdog_ops {
int (*ping)(struct watchdog_device *);
unsigned int (*status)(struct watchdog_device *);
int (*set_timeout)(struct watchdog_device *, unsigned int);
+   int (*set_pretimeout)(struct watchdog_device *, unsigned int);
unsigned int (*get_timeleft)(struct watchdog_device *);
void (*ref)(struct watchdog_device *);
void (*unref)(struct watchdog_device *);
@@ -163,6 +166,15 @@ they are supported. These optional routines/operations are:
   because the watchdog does not necessarily has a 1 second resolution).
   (Note: the WDIOF_SETTIMEOUT needs to be set in the options field of the
   watchdog's info structure).
+* set_pretimeout: this routine check and changes the pre_timeout value of
+  the watchdog, because some watchdog device can trigger the pre_timeout
+  interrupt before watchdog timeout event happened, so that we have chance
+  to save some critical information or something else before watchdog
+  triggered. The pre_timeout value means the number of seconds before
+  watchdog timeout.It returns 0 on success, -EINVAL for "parameter out
+  of range" and and -EIO for "could not write value to the watchdog".
+  (Note: the WDIOF_SETPRETIMEOUT needs to be set in the options field of the
+  watchdog's info structure).
 * get_timeleft: this routines returns the time that's left before a reset.
 * ref: the operation that calls kref_get on the kref of a dynamically
   allocated watchdog_device struct.
diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index 6aaefba..f4a02e5 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -218,6 +218,37 @@ out_timeout:
 }
 
 /*
+ * watchdog_set_pretimeout: set the watchdog timer pretimeout
+ * @wddev: the watchdog device to set the timeout for
+ * @timeout: pretimeout to set in seconds
+ */
+
+static int watchdog_set_pretimeout(struct watchdog_device *wddev,
+  unsigned int timeout)
+{
+   int err;
+
+   if (!wddev->ops->set_pretimeout ||
+   !(wddev->info->options & WDIOF_PRETIMEOUT))
+   return -EOPNOTSUPP;
+   if (watchdog_pretimeout_invalid(wddev, timeout))
+   return -EINVAL;
+
+   mutex_lock(&wddev->lock);
+
+   if (test_bit(WDOG_UNREGISTERED, &wddev->status)) {
+   err = -ENODEV;
+   goto out_timeout;
+   }
+
+   err = wddev->ops->set_pretimeout(wddev, timeout);
+
+out_timeout:
+   mutex_unlock(&wddev->lock);
+   return err;
+}
+
+/*
  * watchdog_get_timeleft: wrapper to get the time left before a reboot
  * @wddev: the watchdog device to get the remaining time from
  * @timeleft: the time that's left
@@ -393,6 +424,12 @@ static long watchdog_ioctl(struct file *file, unsigned int 
cmd,
if (err)
return err;
return put_user(val, p);
+   case WDIOC_SETPRETIMEOUT:
+   if (get_user(val, p))
+   return -EFAULT;
+   return watchdog_set_pretimeout(wdd, val);
+   case WDIOC_GETPRETIMEOUT:
+   return put_user(wdd->pretimeout, p);
default:
return -ENOTTY;
}
diff --git a/include/linux/watchdog.h b/include/linux/watchdog.h
index d74a0e9..281b949 100644
--- a/include/linux/watchdog.h
+++ b/include/linux/watchdog.h
@@ -25,6 +25,7 @@ struct watchdog_device;
  * @pi

Re: [PATCH v2] pwm-backlight: fix the panel power sequence

[YH Huang]

On Fri, 2015-10-30 at 11:34 +0100, Philipp Zabel wrote:
> Am Freitag, den 30.10.2015, 15:41 +0800 schrieb YH Huang:
> > > That won't work if the gpio is still configured as input. How about I
> > > add the GPIOD_ASIS change to my patch you remove that and the above from
> > > yours?
> > 
> > I revise these two lines 
> > if (pb->enable_gpio)
> > gpiod_direction_output(pb->enable_gpio, 0);
> > into
> > if (pb->enable_gpio) {
> > if(gpiod_get_value(pb->enable_gpio) == 0)
> > gpiod_direction_output(pb->enable_gpio, 0);
> > else
> > gpiod_direction_output(pb->enable_gpio, 1);
> > }
> 
> If the GPIO is still configured as an input, the return value of
> gpiod_get_value could be random.
> 
> > I am not sure what "phandle" is working for.
> 
> The reasoning is that devices where there is no phandle link pointing to
> the backlight (for example from a simple-panel node), we should keep the
> current default behaviour (enable during probe).

I have a little problem for the current default behaviour.
Should we enable during probe?

Before this patch ( http://patchwork.ozlabs.org/patch/324690/ ),
we disable "enable-gpio" in the probe function.

Do you have any idea of this?

Regards,
YH Huang


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 03/12] usb: xhci: dbc: probe and setup xhci debug capability

[Lu Baolu]

xHCI debug capability (DbC) is an optional functionality provided
by an xHCI host controller. Software learns this capability by
walking through the extended capability list in mmio of the host.

This patch introduces the code to probe and initialize the debug
capability hardware during early boot. With hardware initialization
done, the debug target (system under debug which has DbC enabled)
will present a debug device through the debug port. The debug device
is fully compliant with the USB framework and provides the equivalent
of a very high performance (USB3) full-duplex serial link between the
debug host and target.

Signed-off-by: Lu Baolu 
---
 MAINTAINERS  |   7 +
 arch/x86/Kconfig.debug   |  12 +
 drivers/usb/early/Makefile   |   1 +
 drivers/usb/early/xhci-dbc.c | 787 +++
 include/linux/usb/xhci-dbc.h | 187 ++
 5 files changed, 994 insertions(+)
 create mode 100644 drivers/usb/early/xhci-dbc.c
 create mode 100644 include/linux/usb/xhci-dbc.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 0425167..585a369 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11040,6 +11040,13 @@ S: Supported
 F: drivers/usb/host/xhci*
 F: drivers/usb/host/pci-quirks*
 
+USB XHCI DEBUG PORT
+M: Lu Baolu 
+L: linux-...@vger.kernel.org
+S: Supported
+F: drivers/usb/early/xhci-dbc.c
+F: include/linux/usb/xhci-dbc.h
+
 USB ZD1201 DRIVER
 L: linux-wirel...@vger.kernel.org
 W: http://linux-lc100020.sourceforge.net
diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index d8c0d32..8d95abd 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -65,6 +65,18 @@ config EARLY_PRINTK_EFI
  This is useful for kernel debugging when your machine crashes very
  early before the console code is initialized.
 
+config EARLY_PRINTK_XDBC
+   bool "Early printk via xHCI debug port"
+   depends on EARLY_PRINTK && PCI
+   ---help---
+ Write kernel log output directly into the xHCI debug port.
+
+ This is useful for kernel debugging when your machine crashes very
+ early before the console code is initialized. For normal operation
+ it is not recommended because it looks ugly and doesn't cooperate
+ with klogd/syslogd or the X server. You should normally N here,
+ unless you want to debug such a crash.
+
 config X86_PTDUMP
bool "Export kernel pagetable layout to userspace via debugfs"
depends on DEBUG_KERNEL
diff --git a/drivers/usb/early/Makefile b/drivers/usb/early/Makefile
index 24bbe51..2db5906 100644
--- a/drivers/usb/early/Makefile
+++ b/drivers/usb/early/Makefile
@@ -3,3 +3,4 @@
 #
 
 obj-$(CONFIG_EARLY_PRINTK_DBGP) += ehci-dbgp.o
+obj-$(CONFIG_EARLY_PRINTK_XDBC) += xhci-dbc.o
diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
new file mode 100644
index 000..22a1de9
--- /dev/null
+++ b/drivers/usb/early/xhci-dbc.c
@@ -0,0 +1,787 @@
+/**
+ * xhci-dbc.c - xHCI debug capability driver
+ *
+ * Copyright (C) 2015 Intel Corporation
+ *
+ * Author: Lu Baolu 
+ * Some code shared with EHCI debug port and xHCI driver.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../host/xhci.h"
+
+#defineXDBC_PROTOCOL   1   /* GNU Remote Debug Command Set 
*/
+#defineXDBC_VENDOR_ID  0x1d6b  /* Linux Foundation 0x1d6b */
+#defineXDBC_PRODUCT_ID 0x0004  /* __le16 idProduct; device 
0004 */
+#defineXDBC_DEVICE_REV 0x0010  /* 0.10 */
+
+static struct xdbc_state xdbc_stat;
+static struct xdbc_state *xdbcp = &xdbc_stat;
+
+#ifdef DBC_DEBUG
+/* place holder */
+#definexdbc_trace  printk
+static void xdbc_dbg_dump_regs(char *str)
+{
+   if (!xdbcp->xdbc_reg) {
+   xdbc_trace("register not mapped\n");
+   return;
+   }
+
+   xdbc_trace("XDBC registers: %s\n", str);
+   xdbc_trace("  Capability: %08x\n",
+   readl(&xdbcp->xdbc_reg->capability));
+   xdbc_trace("  Door bell: %08x\n",
+   readl(&xdbcp->xdbc_reg->doorbell));
+   xdbc_trace("  Event Ring Segment Table Size: %08x\n",
+   readl(&xdbcp->xdbc_reg->ersts));
+   xdbc_trace("  Event Ring Segment Table Base Address: %16llx\n",
+   xdbc_read64(&xdbcp->xdbc_reg->erstba));
+   xdbc_trace("  Event Ring Dequeue Pointer: %16llx\n",
+   xdbc_read64(&xdbcp->xdbc_reg->erdp));
+   xdbc_trace("  Port status and control: %08x\n",
+   readl(&xdbcp->xdbc_reg->portsc));
+   xdbc_trace("  Debug Capability Context Pointer: %16llx\n",
+   xdbc_rea

[PATCH v2 04/12] usb: xhci: dbc: add support for Intel xHCI dbc quirk

[Lu Baolu]

On Intel platform, if the debug target is connected with debug
host, enabling DCE bit in command register leads to a hung bus
state. In the hung state, the host system will not see a port
connected status bit set. Hence debug target fails to be probed.

The state could be resolved by performing a port reset to the
debug port from the host xHCI. This patch introduces this work
around.

Signed-off-by: Lu Baolu 
---
 drivers/usb/early/xhci-dbc.c | 52 
 include/linux/usb/xhci-dbc.h |  2 ++
 2 files changed, 54 insertions(+)

diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index 22a1de9..6b23f09 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -255,6 +255,8 @@ static void __iomem *xdbc_map_pci_mmio(u32 bus,
xdbcp->bar = bar;
xdbcp->xhci_base = base;
xdbcp->xhci_length = sz64;
+   xdbcp->vendor = read_pci_config_16(bus, dev, func, PCI_VENDOR_ID);
+   xdbcp->device = read_pci_config_16(bus, dev, func, PCI_DEVICE_ID);
 
if (length)
*length = sz64;
@@ -651,6 +653,52 @@ static int xdbc_mem_init(void)
return 0;
 }
 
+static void xdbc_reset_debug_port_callback(int cap_offset, void *data)
+{
+   u8 major;
+   u32 val, port_offset, port_count;
+   u32 cap_length;
+   void __iomem *ops_reg;
+   void __iomem *portsc;
+   int i;
+
+   val = readl(xdbcp->xhci_base + cap_offset);
+   major = (u8) XHCI_EXT_PORT_MAJOR(val);
+
+   /* only reset super-speed port */
+   if (major != 0x3)
+   return;
+
+   val = readl(xdbcp->xhci_base + cap_offset + 8);
+   port_offset = XHCI_EXT_PORT_OFF(val);
+   port_count = XHCI_EXT_PORT_COUNT(val);
+   xdbc_trace("Extcap Port offset %d count %d\n",
+   port_offset, port_count);
+
+   cap_length = readl(xdbcp->xhci_base) & 0xff;
+   ops_reg = xdbcp->xhci_base + cap_length;
+
+   port_offset--;
+   for (i = port_offset; i < (port_offset + port_count); i++) {
+   portsc = ops_reg + 0x400 + i * 0x10;
+   val = readl(portsc);
+   /* reset the port if CCS bit is cleared */
+   if (!(val & 0x1))
+   writel(val | (1 << 4), portsc);
+   }
+}
+
+static void xdbc_reset_debug_port(void)
+{
+   xdbc_walk_excap(xdbcp->bus,
+   xdbcp->dev,
+   xdbcp->func,
+   XHCI_EXT_CAPS_PROTOCOL,
+   false,
+   xdbc_reset_debug_port_callback,
+   NULL);
+}
+
 /*
  * xdbc_start: start DbC
  *
@@ -669,6 +717,10 @@ static int xdbc_start(void)
return -ENODEV;
}
 
+   /* reset port to avoid bus hang */
+   if (xdbcp->vendor == PCI_VENDOR_ID_INTEL)
+   xdbc_reset_debug_port();
+
/* wait for port connection */
if (handshake(&xdbcp->xdbc_reg->portsc, PORTSC_CCS,
PORTSC_CCS, 500, 100) < 0) {
diff --git a/include/linux/usb/xhci-dbc.h b/include/linux/usb/xhci-dbc.h
index 153fb87..fc0ef9a 100644
--- a/include/linux/usb/xhci-dbc.h
+++ b/include/linux/usb/xhci-dbc.h
@@ -128,6 +128,8 @@ struct xdbc_state {
u32 dev;
u32 func;
u8  bar;
+   u16 vendor;
+   u16 device;
void __iomem*xhci_base;
size_t  xhci_length;
 #defineXDBC_PCI_MAX_BUSES  256
-- 
2.1.4

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

[PATCH v2 06/12] usb: xhci: dbc: add bulk out and bulk in interfaces

[Lu Baolu]

This patch adds interfaces for bulk out and bulk in ops. These
interfaces could be used to implement early printk bootconsole
or hook to various system debuggers.

Signed-off-by: Lu Baolu 
---
 drivers/usb/early/xhci-dbc.c | 373 +++
 include/linux/usb/xhci-dbc.h |  30 
 2 files changed, 403 insertions(+)

diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index b36a527..f51daa4 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -219,11 +219,21 @@ static void xdbc_dbg_dump_data(char *str)
xdbc_dbg_dump_string("String Descriptor:");
 }
 
+static void xdbc_dbg_dump_trb(struct xdbc_trb *trb, char *str)
+{
+   xdbc_trace("DBC trb: %s\n", str);
+   xdbc_trace("@%016llx %08x %08x %08x %08x\n", (u64)__pa(trb),
+   le32_to_cpu(trb->field[0]),
+   le32_to_cpu(trb->field[1]),
+   le32_to_cpu(trb->field[2]),
+   le32_to_cpu(trb->field[3]));
+}
 #else
 static inline void xdbc_trace(const char *fmt, ...) { }
 static inline void xdbc_dump_debug_buffer(void) { }
 static inline void xdbc_dbg_dump_regs(char *str) { }
 static inline void xdbc_dbg_dump_data(char *str) { }
+static inline void xdbc_dbg_dump_trb(struct xdbc_trb *trb, char *str) { }
 #endif /* DBC_DEBUG */
 
 /*
@@ -334,6 +344,7 @@ static void *xdbc_get_page(dma_addr_t *dma_addr,
static char in_ring_page[PAGE_SIZE] __aligned(PAGE_SIZE);
static char out_ring_page[PAGE_SIZE] __aligned(PAGE_SIZE);
static char table_page[PAGE_SIZE] __aligned(PAGE_SIZE);
+   static char bulk_buf_page[PAGE_SIZE] __aligned(PAGE_SIZE);
 
switch (type) {
case XDBC_PAGE_EVENT:
@@ -348,6 +359,9 @@ static void *xdbc_get_page(dma_addr_t *dma_addr,
case XDBC_PAGE_TABLE:
virt = (void *)table_page;
break;
+   case XDBC_PAGE_BUFFER:
+   virt = (void *)bulk_buf_page;
+   break;
default:
return NULL;
}
@@ -707,6 +721,12 @@ static int xdbc_mem_init(void)
dev_info = cpu_to_le32((XDBC_DEVICE_REV << 16) | XDBC_PRODUCT_ID);
writel(dev_info, &xdbcp->xdbc_reg->devinfo2);
 
+   /* get and store the transfer buffer */
+   xdbcp->out_buf = xdbc_get_page(&xdbcp->out_dma,
+   XDBC_PAGE_BUFFER);
+   xdbcp->in_buf = xdbcp->out_buf + XDBC_MAX_PACKET;
+   xdbcp->in_dma = xdbcp->out_dma + XDBC_MAX_PACKET;
+
return 0;
 }
 
@@ -802,6 +822,9 @@ static int xdbc_start(void)
 
xdbc_trace("root hub port number %d\n", DCST_DPN(status));
 
+   xdbcp->in_ep_state = EP_RUNNING;
+   xdbcp->out_ep_state = EP_RUNNING;
+
xdbc_trace("DbC is running now, control 0x%08x\n",
readl(&xdbcp->xdbc_reg->control));
 
@@ -895,3 +918,353 @@ int __init early_xdbc_init(char *s)
 
return 0;
 }
+
+static void xdbc_queue_trb(struct xdbc_ring *ring,
+   u32 field1, u32 field2, u32 field3, u32 field4)
+{
+   struct xdbc_trb *trb, *link_trb;
+
+   trb = ring->enqueue;
+   trb->field[0] = cpu_to_le32(field1);
+   trb->field[1] = cpu_to_le32(field2);
+   trb->field[2] = cpu_to_le32(field3);
+   trb->field[3] = cpu_to_le32(field4);
+
+   xdbc_dbg_dump_trb(trb, "enqueue trb");
+
+   ++(ring->enqueue);
+   if (ring->enqueue >= &ring->segment->trbs[TRBS_PER_SEGMENT - 1]) {
+   link_trb = ring->enqueue;
+   if (ring->cycle_state)
+   link_trb->field[3] |= cpu_to_le32(TRB_CYCLE);
+   else
+   link_trb->field[3] &= cpu_to_le32(~TRB_CYCLE);
+
+   ring->enqueue = ring->segment->trbs;
+   ring->cycle_state ^= 1;
+   }
+}
+
+static void xdbc_ring_doorbell(int target)
+{
+   writel(DOOR_BELL_TARGET(target), &xdbcp->xdbc_reg->doorbell);
+}
+
+static void xdbc_handle_port_status(struct xdbc_trb *evt_trb)
+{
+   u32 port_reg;
+
+   port_reg = readl(&xdbcp->xdbc_reg->portsc);
+
+   if (port_reg & PORTSC_CSC) {
+   xdbc_trace("%s: connect status change event\n", __func__);
+   writel(port_reg | PORTSC_CSC, &xdbcp->xdbc_reg->portsc);
+   port_reg = readl(&xdbcp->xdbc_reg->portsc);
+   }
+
+   if (port_reg & PORTSC_PRC) {
+   xdbc_trace("%s: port reset change event\n", __func__);
+   writel(port_reg | PORTSC_PRC, &xdbcp->xdbc_reg->portsc);
+   port_reg = readl(&xdbcp->xdbc_reg->portsc);
+   }
+
+   if (port_reg & PORTSC_PLC) {
+   xdbc_trace("%s: port link status change event\n", __func__);
+   writel(port_reg | PORTSC_PLC, &xdbcp->xdbc_reg->portsc);
+   port_reg = readl(&xdbcp->xdbc_reg->portsc);
+   }
+
+   if (port_reg & PORTSC_CEC) {
+   xdbc_trace("%s: config error change\n", __func__)

[RESEND PATCH 0/1] Fix the "hard LOCKUP" when running a heavy loading

[Caesar Wang]

As the following log:
where we experience a CPU hard lockup. The assembly code (disassembled by gdb)

0xc06c6e90 <__tcp_select_window+148>:beq 
0xc06c6eb0<__tcp_select_window+180>
0xc06c6e94 <__tcp_select_window+152>:mov r2, #1008; 0x3f0
0xc06c6e98 <__tcp_select_window+156>:ldr r5, [r0,#1004] ; 0x3ec
0xc06c6e9c <__tcp_select_window+160>:ldrhr2, [r0,r2]


0xc06c6ee0 <__tcp_select_window+228>:addne   r0, r0, #1
0xc06c6ee4 <__tcp_select_window+232>:lslne   r0, r0, r2
0xc06c6ee8 <__tcp_select_window+236>:ldmne   sp, {r4, r5,r11, sp,pc}

Could either the “strhi”/”strlo” pair, or the lslne/ldmne pair, be
tripping over errata 818325, or a similar errata?

0xc06c6eec <__tcp_select_window+240>:b   
0xc06c6f40<__tcp_select_window+324>

This is patch can fix the *hard lock* in some case.

As the Russell said:
"in other words, which can be handled by updating a control register in the 
firmware or
boot loader"
Maybe the better solution is in firmware.

Others, I'm no sure this workaround patch if can be accepted.

I resend this patch for getting some suggestion from you.

--
Thanks!



Huang Tao (1):
  ARM: errata: Workaround for Cortex-A12 erratum 818325

 arch/arm/Kconfig  | 13 +
 arch/arm/mm/proc-v7.S | 12 
 2 files changed, 25 insertions(+)

-- 
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 v3 1/4] perf report: Support folded callchain mode on --stdio

[Jiri Olsa]

On Tue, Nov 03, 2015 at 04:18:28PM +0900, Namhyung Kim wrote:
> Add new call chain option (-g) 'folded' to print callchains in a line.
> The callchains are separated by semicolons, and preceded by (absolute)
> percent values and a space.
> 
> For example, following 20 lines can be printed in 3 lines with the
> folded output mode;
> 
>   $ perf report -g flat --no-children | grep -v ^# | head -20
>   60.48%  swapper  [kernel.vmlinux]  [k] intel_idle
>   54.60%
>  intel_idle
>  cpuidle_enter_state
>  cpuidle_enter
>  call_cpuidle
>  cpu_startup_entry
>  start_secondary
> 
>   5.88%
>  intel_idle
>  cpuidle_enter_state
>  cpuidle_enter
>  call_cpuidle
>  cpu_startup_entry
>  rest_init
>  start_kernel
>  x86_64_start_reservations
>  x86_64_start_kernel
> 
>   $ perf report -g folded --no-children | grep -v ^# | head -3
>   60.48%  swapper  [kernel.vmlinux]  [k] intel_idle
>   54.60% 
> intel_idle;cpuidle_enter_state;cpuidle_enter;call_cpuidle;cpu_startup_entry;start_secondary
>   5.88% 
> intel_idle;cpuidle_enter_state;cpuidle_enter;call_cpuidle;cpu_startup_entry;rest_init;start_kernel;x86_64_start_reservations;x86_64_start_kernel
> 
> This mode is supported only for --stdio now and intended to be used by
> some scripts like in FlameGraphs[1].  Support for other UI might be
> added later.
> 
> [1] http://www.brendangregg.com/FlameGraphs/cpuflamegraphs.html
> 
> Requested-by: Brendan Gregg 
> Signed-off-by: Namhyung Kim 
> ---
>  tools/perf/ui/stdio/hist.c  | 54 
> +
>  tools/perf/util/callchain.c |  6 +
>  tools/perf/util/callchain.h |  3 ++-
>  3 files changed, 62 insertions(+), 1 deletion(-)

missing doc update, otherwise

Acked-by: Jiri Olsa 

thanks,
jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/6] arm64: Simple additions to NS2 DT

[Anup Patel]

+Arnd, +Olof

Ping?

Regards,
Anup
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] mfd: cros ec: Lock the SPI bus while holding chipselect

[Nicolas Boichat]

+gwen...@chromium.org

On Thu, Oct 29, 2015 at 4:17 PM, Nicolas Boichat  wrote:
> @@ -482,6 +493,7 @@ static int cros_ec_pkt_xfer_spi(struct cros_ec_device 
> *ec_dev,
>
> ret = len;
>  exit:
> +   spi_bus_unlock(ec_spi->spi->master);

Gwendal noted offline that I could unlock the bus earlier, just after
terminate_request.

I'll do that and send a v2 soon.

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 v5 0/3] NAND support for Broadcom NS2 SoC

[Anup Patel]

+Arnd, +Olof

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

details required

i have a business proposal for you with urgent transfer notice please send me 
reply to maekhalsa...@gmail.com or my official email sa...@iraqrepvp.comze.com 
with your
contact details and personal mobile number if you are interested.

you can also call me at my direct sattelite number +447937455418 for detailed 
discussion

regards
maekhal salem

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 07/12] usb: xhci: dbc: handle dbc-configured exit

[Lu Baolu]

DbC might exit configured state in some cases (refer to 7.6.4.4 in
xHCI spec 1.1). Software needs detect and clear this situation by
clearing DCCTRL.DCR and wait until the DbC configured before read
or write oprations.

Signed-off-by: Lu Baolu 
---
 drivers/usb/early/xhci-dbc.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index f51daa4..8a5a51f 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -1153,6 +1153,29 @@ static int xdbc_wait_until_bulk_done(struct xdbc_trb 
*trb, int loops)
return -EIO;
 }
 
+static int xdbc_wait_until_dbc_configured(void)
+{
+   int timeout = 0;
+   u32 reg;
+
+   /* Port exits configured state */
+   reg = readl(&xdbcp->xdbc_reg->control);
+   if (!(reg & CTRL_DRC))
+   return 0;
+
+   /* clear run change bit (RW1C) */
+   writel(reg | CTRL_DRC, &xdbcp->xdbc_reg->control);
+
+   do {
+   if (readl(&xdbcp->xdbc_reg->control) & CTRL_DCR)
+   return 0;
+
+   xdbc_udelay(10);
+   } while (timeout++ < XDBC_LOOPS);
+
+   return -ETIMEDOUT;
+}
+
 static int xdbc_bulk_transfer(void *data, int size, int loops, bool read)
 {
u64 addr;
@@ -1167,6 +1190,11 @@ static int xdbc_bulk_transfer(void *data, int size, int 
loops, bool read)
return -EINVAL;
}
 
+   if (xdbc_wait_until_dbc_configured()) {
+   xdbc_trace("%s: hardware not ready\n", __func__);
+   return -EPERM;
+   }
+
ring = (read ? &xdbcp->in_ring : &xdbcp->out_ring);
trb = ring->enqueue;
cycle = ring->cycle_state;
-- 
2.1.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/

[GIT PULL] Security subsystem update for 4.4

[James Morris]

Please pull.

This is mostly maintenance updates across the subsystem, with a notable 
update for TPM 2.0, and addition of Jarkko Sakkinen as a maintainer of 
that.

The following changes since commit 5062ecdb662bf3aed6dc975019c53ffcd3b01d1c:

  Merge tag 'regmap-v4.4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap (2015-11-02 
16:16:24 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security.git next

Arnd Bergmann (1):
  apparmor: clarify CRYPTO dependency

David Howells (3):
  KEYS: Provide a script to extract the sys cert list from a vmlinux file
  KEYS: Provide a script to extract a module signature
  KEYS: Merge the type-specific data with the payload data

Dmitry Kasatkin (1):
  integrity: prevent loading untrusted certificates on the IMA trusted 
keyring

Geert Uytterhoeven (1):
  tpm: Allow compile test of GPIO consumers if !GPIOLIB

Geliang Tang (3):
  smack: smk_ipv6_port_list should be static
  KEYS: use kvfree() in add_key
  selinux: ioctl_has_perm should be static

Hon Ching \(Vicky\) Lo (6):
  vTPM: fix memory allocation flag for rtce buffer at kernel boot
  vTPM: fix searching for the right vTPM node in device tree
  vTPM: reformat event log to be byte-aligned
  vTPM: get the buffer allocated for event log instead of the actual log
  vTPM: support little endian guests
  TPM: remove unnecessary little endian conversion

Insu Yun (1):
  keys: Be more consistent in selection of union members used

James Morris (4):
  Merge branch 'next' of git://git.kernel.org/.../zohar/linux-integrity 
into next
  Merge branch 'smack-for-4.4' of https://github.com/cschaufler/smack-next 
into next
  Merge branch 'upstream' of git://git.infradead.org/users/pcmoore/selinux 
into next
  Merge tag 'keys-next-20151021' of 
git://git.kernel.org/.../dhowells/linux-fs into next

Jarkko Sakkinen (10):
  tpm, tpm_crb: fix unaligned read of the command buffer address
  tpm, tpm_tis: fix tpm_tis ACPI detection issue with TPM 2.0
  sysfs: added __compat_only_sysfs_link_entry_to_kobj()
  tpm: move the PPI attributes to character device directory.
  tpm: update PPI documentation to address the location change.
  tpm: introduce tpm_buf
  keys, trusted: move struct trusted_key_options to trusted-type.h
  tpm: seal/unseal for TPM 2.0
  keys, trusted: seal/unseal with TPM 2.0 chips
  MAINTAINERS: add new maintainer for TPM DEVICE DRIVER

Jeff Vander Stoep (1):
  selinux: do not check open perm on ftruncate call

José Bollo (1):
  Smack: Minor initialisation improvement

Krzysztof Kozlowski (1):
  char: Drop owner assignment from i2c_driver

Lukasz Pawelczyk (1):
  Smack: fix a NULL dereference in wrong smack_import_entry() usage

Paul Gortmaker (1):
  certs: add .gitignore to stop git nagging about x509_certificate_list

Paul Moore (1):
  selinux: change CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE default

Rasmus Villemoes (5):
  selinux: introduce security_context_str_to_sid
  selinux: remove pointless cast in selinux_inode_setsecurity()
  selinux: use kmemdup in security_sid_to_context_core()
  selinux: use kstrdup() in security_get_bools()
  selinux: use sprintf return value

Roman Kubiak (1):
  Smack: pipefs fix in smack_d_instantiate

Sangwoo (1):
  selinux: Use a kmem_cache for allocation struct file_security_struct

Zbigniew Jasinski (1):
  Smack: limited capability for changing process label

 Documentation/ABI/testing/sysfs-driver-ppi   |   19 +-
 Documentation/crypto/asymmetric-keys.txt |   27 ++--
 Documentation/security/Smack.txt |   10 +
 Documentation/security/keys.txt  |   41 +++--
 MAINTAINERS  |1 +
 arch/powerpc/kernel/prom_init.c  |   40 +++-
 certs/.gitignore |4 +
 crypto/asymmetric_keys/asymmetric_keys.h |5 -
 crypto/asymmetric_keys/asymmetric_type.c |   44 +++--
 crypto/asymmetric_keys/public_key.c  |4 +-
 crypto/asymmetric_keys/signature.c   |2 +-
 crypto/asymmetric_keys/x509_parser.h |1 +
 crypto/asymmetric_keys/x509_public_key.c |9 +-
 drivers/char/tpm/st33zp24/Kconfig|2 +-
 drivers/char/tpm/st33zp24/i2c.c  |1 -
 drivers/char/tpm/tpm-chip.c  |   24 ++-
 drivers/char/tpm/tpm-interface.c |   76 +++
 drivers/char/tpm/tpm.h   |  134 +++-
 drivers/char/tpm/tpm2-cmd.c  |  250 +-
 drivers/char/tpm/tpm_crb.c   |   39 ++--
 drivers/char/tpm/tpm_eventlog.c  |   78 +--
 drivers/char/tpm/tpm_eventlog.h  |6 +
 drivers/char/tpm/tpm_i2c_atmel.c 

[PATCH v2 02/12] x86: fixmap: add permanent fixmap for xhci debug port

[Lu Baolu]

xHCI compatible USB3 host controller may provide debug capability
which enables low-level system debug over USB. In order to probing
this debug capability, Linux kernel needs to map and access the
mmio of the host controller during early boot.

This patch adds permenent fixmap pages in fixed_addresses table for
xHCI mmio access.

Signed-off-by: Lu Baolu 
---
 arch/x86/include/asm/fixmap.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
index f80d700..fbf452f 100644
--- a/arch/x86/include/asm/fixmap.h
+++ b/arch/x86/include/asm/fixmap.h
@@ -82,6 +82,10 @@ enum fixed_addresses {
 #ifdef CONFIG_PROVIDE_OHCI1394_DMA_INIT
FIX_OHCI1394_BASE,
 #endif
+#ifdef CONFIG_EARLY_PRINTK_XDBC
+   FIX_XDBC_BASE,
+   FIX_XDBC_END = FIX_XDBC_BASE + 15,
+#endif
 #ifdef CONFIG_X86_LOCAL_APIC
FIX_APIC_BASE,  /* local (CPU) APIC) -- required for SMP or not */
 #endif
-- 
2.1.4

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

[PATCH v2 00/12] usb: early: add support for early printk through USB3 debug port

[Lu Baolu]

This patch series adds support for early printk through USB3 debug port.
USB3 debug port is described in xHCI specification as an optional extended
capability.

The first patch adds a file in sysfs, through which users can check
whether the debug capability is supported by a specific host controller,
and the hardware state.

Patch 2 to 10 add the driver for xHCI debug capability. It interfaces with
the register set and provides the required ops (read/write/control) to upper
layers. Early printk is one consumer of these ops. The hooks for early printk
are introduced in patch 9. This design is similar to what we have done in
drivers/usb/early/ehci-dbgp.c.

Patch 11 is a minor change to usb_debug module. This change is required to
bind usb_debug with the USB3 debug device.

Patch 12 is the design document and user guide.

Change log:
v1->v2:
(1) Patch 1 re-implemented. "debugfs" has been replaced with sysfs.
The scope reduced from all extended capabilities to debug port
specific.
(2) Patch 11 changed. Removed unnecessary .bulk_out_size setting.

Lu Baolu (12):
  usb: xhci: add sysfs file for xHCI debug port
  x86: fixmap: add permanent fixmap for xhci debug port
  usb: xhci: dbc: probe and setup xhci debug capability
  usb: xhci: dbc: add support for Intel xHCI dbc quirk
  usb: xhci: dbc: add debug buffer
  usb: xhci: dbc: add bulk out and bulk in interfaces
  usb: xhci: dbc: handle dbc-configured exit
  usb: xhci: dbc: handle endpoint stall
  x86: early_printk: add USB3 debug port earlyprintk support
  usb: xhci: dbc: add handshake between debug target and host
  usb: serial: usb_debug: add support for dbc debug device
  usb: doc: add document for xHCI DbC driver

 .../ABI/testing/sysfs-bus-pci-drivers-xhci_hcd |   23 +
 Documentation/kernel-parameters.txt|1 +
 Documentation/usb/xhci-dbc.txt |  325 +
 MAINTAINERS|8 +
 arch/x86/Kconfig.debug |   12 +
 arch/x86/include/asm/fixmap.h  |4 +
 arch/x86/kernel/early_printk.c |5 +
 drivers/usb/early/Makefile |1 +
 drivers/usb/early/xhci-dbc.c   | 1407 
 drivers/usb/host/Makefile  |2 +-
 drivers/usb/host/xhci-ext-caps.h   |   14 +-
 drivers/usb/host/xhci-sysfs.c  |  100 ++
 drivers/usb/host/xhci.c|4 +
 drivers/usb/host/xhci.h|4 +
 drivers/usb/serial/usb_debug.c |   28 +-
 include/linux/usb/xhci-dbc.h   |  224 
 16 files changed, 2157 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd
 create mode 100644 Documentation/usb/xhci-dbc.txt
 create mode 100644 drivers/usb/early/xhci-dbc.c
 create mode 100644 drivers/usb/host/xhci-sysfs.c
 create mode 100644 include/linux/usb/xhci-dbc.h

-- 
2.1.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 v2 4/4] ocfs2: check/fix inode block for online file check

[Gang He]

Hello Junxiao,

See my comments inline.


>>> 
> Hi Gang,
> 
> This is not like a right patch.
> First, online file check only checks inode's block number, valid flag,
> fs generation value, and meta ecc. I never see a real corruption
> happened only on this field, if these fields are corrupted, that means
> something bad may happen on other place. So fix this field may not help
> and even cause corruption more hard.
This online file check/fix feature is used to check/fix some light file meta 
block corruption, instead of turning a file system off and using fsck.ocfs2.
e.g. meta ecc error, we really need not to use fsck.ocfs2. 
of course, this feature does not replace fsck.ocfs2 and touch some complicated 
meta block problems, if there is some potential problem in some areas, we can 
discuss them one by one.



> Second, the repair way is wrong. In
> ocfs2_filecheck_repair_inode_block(), if these fields in disk don't
> match the ones in memory, the ones in memory are used to update the disk
> fields. The question is how do you know these field in memory are
> right(they may be the real corrupted ones)?
Here, if the inode block was corrupted, the file system is not able to load it 
into the memory.
ocfs2_filecheck_repair_inode_block() will able to load it into the memory, 
since it try to fix these light-level problem before loading.
if the fix is OK, the changed meta-block can pass the block-validate function 
and load into the memory as a inode object.
Since the file system is under a cluster environment, we have to use some 
existing function and code path to keep these block operation under a cluster 
lock.


Thanks
Gang

> 
> Thanks,
> Junxiao.
> On 10/28/2015 02:26 PM, Gang He wrote:
>> +static int ocfs2_filecheck_repair_inode_block(struct super_block *sb,
>> +   struct buffer_head *bh)
>> +{
>> +int rc;
>> +int changed = 0;
>> +struct ocfs2_dinode *di = (struct ocfs2_dinode *)bh->b_data;
>> +
>> +rc = ocfs2_filecheck_validate_inode_block(sb, bh);
>> +/* Can't fix invalid inode block */
>> +if (!rc || rc == -OCFS2_FILECHECK_ERR_INVALIDINO)
>> +return rc;
>> +
>> +trace_ocfs2_filecheck_repair_inode_block(
>> +(unsigned long long)bh->b_blocknr);
>> +
>> +if (ocfs2_is_hard_readonly(OCFS2_SB(sb)) ||
>> +ocfs2_is_soft_readonly(OCFS2_SB(sb))) {
>> +mlog(ML_ERROR,
>> +"Filecheck: try to repair dinode #%llu on readonly 
>> filesystem\n",
>> +(unsigned long long)bh->b_blocknr);
>> +return -OCFS2_FILECHECK_ERR_READONLY;
>> +}
>> +
>> +if (le64_to_cpu(di->i_blkno) != bh->b_blocknr) {
>> +di->i_blkno = cpu_to_le64(bh->b_blocknr);
>> +changed = 1;
>> +mlog(ML_ERROR,
>> +"Filecheck: reset dinode #%llu: i_blkno to %llu\n",
>> +(unsigned long long)bh->b_blocknr,
>> +(unsigned long long)le64_to_cpu(di->i_blkno));
>> +}
>> +
>> +if (!(di->i_flags & cpu_to_le32(OCFS2_VALID_FL))) {
>> +di->i_flags |= cpu_to_le32(OCFS2_VALID_FL);
>> +changed = 1;
>> +mlog(ML_ERROR,
>> +"Filecheck: reset dinode #%llu: OCFS2_VALID_FL is 
>> set\n",
>> +(unsigned long long)bh->b_blocknr);
>> +}
>> +
>> +if (le32_to_cpu(di->i_fs_generation) !=
>> +OCFS2_SB(sb)->fs_generation) {
>> +di->i_fs_generation = cpu_to_le32(OCFS2_SB(sb)->fs_generation);
>> +changed = 1;
>> +mlog(ML_ERROR,
>> +"Filecheck: reset dinode #%llu: fs_generation to %u\n",
>> +(unsigned long long)bh->b_blocknr,
>> +le32_to_cpu(di->i_fs_generation));
>> +}
>> +
>> +if (changed ||
>> +ocfs2_validate_meta_ecc(sb, bh->b_data, &di->i_check)) {
>> +ocfs2_compute_meta_ecc(sb, bh->b_data, &di->i_check);
>> +mark_buffer_dirty(bh);
>> +mlog(ML_ERROR,
>> +"Filecheck: reset dinode #%llu: compute meta ecc\n",
>> +(unsigned long long)bh->b_blocknr);
>> +}
>> +
>> +return 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 v2 09/12] x86: early_printk: add USB3 debug port earlyprintk support

[Lu Baolu]

Add support for early printk by writing debug messages to the USB3
debug port. Users can use this type of early printk by specifying
kernel parameter of "earlyprintk=xdbc". This gives users a chance
of providing debug output.

Signed-off-by: Lu Baolu 
---
 Documentation/kernel-parameters.txt |  1 +
 arch/x86/kernel/early_printk.c  |  5 +
 drivers/usb/early/xhci-dbc.c| 43 +
 include/linux/usb/xhci-dbc.h|  5 +
 4 files changed, 54 insertions(+)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 22a4b68..b65b07f 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1032,6 +1032,7 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
earlyprintk=ttySn[,baudrate]
earlyprintk=dbgp[debugController#]
earlyprintk=pciserial,bus:device.function[,baudrate]
+   earlyprintk=xdbc[xhciController#]
 
earlyprintk is useful when the kernel crashes before
the normal console is initialized. It is not enabled by
diff --git a/arch/x86/kernel/early_printk.c b/arch/x86/kernel/early_printk.c
index eec40f5..5341a16 100644
--- a/arch/x86/kernel/early_printk.c
+++ b/arch/x86/kernel/early_printk.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -373,6 +374,10 @@ static int __init setup_early_printk(char *buf)
if (!strncmp(buf, "dbgp", 4) && !early_dbgp_init(buf + 4))
early_console_register(&early_dbgp_console, keep);
 #endif
+#ifdef CONFIG_EARLY_PRINTK_XDBC
+   if (!strncmp(buf, "xdbc", 4) && !early_xdbc_init(buf + 4))
+   early_console_register(&early_xdbc_console, keep);
+#endif
 #ifdef CONFIG_HVC_XEN
if (!strncmp(buf, "xen", 3))
early_console_register(&xenboot_console, keep);
diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index aaf655f..68a7139 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -10,6 +10,7 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
+#include 
 #include 
 #include 
 #include 
@@ -1332,3 +1333,45 @@ int xdbc_bulk_write(const char *bytes, int size)
 
return ret;
 }
+
+/*
+ * Start a bulk-in or bulk-out transfer, wait until transfer completion
+ * or error. Return the count of actually transferred bytes or error.
+ */
+static void early_xdbc_write(struct console *con, const char *str, u32 n)
+{
+   int chunk, ret;
+   static char buf[XDBC_MAX_PACKET];
+   int use_cr = 0;
+
+   if (!xdbcp->xdbc_reg)
+   return;
+   memset(buf, 0, XDBC_MAX_PACKET);
+   while (n > 0) {
+   for (chunk = 0; chunk < XDBC_MAX_PACKET && n > 0;
+str++, chunk++, n--) {
+   if (!use_cr && *str == '\n') {
+   use_cr = 1;
+   buf[chunk] = '\r';
+   str--;
+   n++;
+   continue;
+   }
+   if (use_cr)
+   use_cr = 0;
+   buf[chunk] = *str;
+   }
+   if (chunk > 0) {
+   ret = xdbc_bulk_write(buf, chunk);
+   if (ret < 0)
+   break;
+   }
+   }
+}
+
+struct console early_xdbc_console = {
+   .name = "earlyxdbc",
+   .write =early_xdbc_write,
+   .flags =CON_PRINTBUFFER,
+   .index =-1,
+};
diff --git a/include/linux/usb/xhci-dbc.h b/include/linux/usb/xhci-dbc.h
index 289ba58..a556eb8 100644
--- a/include/linux/usb/xhci-dbc.h
+++ b/include/linux/usb/xhci-dbc.h
@@ -216,4 +216,9 @@ struct xdbc_state {
 #definexdbc_read64(regs)   xhci_read_64(NULL, (regs))
 #definexdbc_write64(val, regs) xhci_write_64(NULL, (val), (regs))
 
+#ifdef CONFIG_EARLY_PRINTK_XDBC
+extern int early_xdbc_init(char *s);
+extern struct console early_xdbc_console;
+#endif /* CONFIG_EARLY_PRINTK_XDBC */
+
 #endif /* __LINUX_XHCI_DBC_H */
-- 
2.1.4

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

[PATCH v2 01/12] usb: xhci: add sysfs file for xHCI debug port

[Lu Baolu]

This patch adds a sysfs file for users to check 1) whether the debug
capability is implemented by hardware; 2) if supported, which state
does it stay at.

With a host that supports debug port, a file named "debug_port_state"
will be created under the device sysfs directory. Reading this file
will show users the state (disabled, enabled or configured) of the
debug port.

With a host that does NOT support debug port, "debug_port_state" file
won't be created.

Signed-off-by: Lu Baolu 
---
 .../ABI/testing/sysfs-bus-pci-drivers-xhci_hcd |  23 +
 drivers/usb/host/Makefile  |   2 +-
 drivers/usb/host/xhci-ext-caps.h   |  14 ++-
 drivers/usb/host/xhci-sysfs.c  | 100 +
 drivers/usb/host/xhci.c|   4 +
 drivers/usb/host/xhci.h|   4 +
 6 files changed, 145 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd
 create mode 100644 drivers/usb/host/xhci-sysfs.c

diff --git a/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd 
b/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd
new file mode 100644
index 000..dd3e722
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd
@@ -0,0 +1,23 @@
+What:  /sys/bus/pci/drivers/xhci_hcd/.../debug_port_state
+Date:  November 2015
+KernelVersion: 4.3.0
+Contact:   Lu Baolu 
+Description:
+   This file is designed for users to check the state of a
+   USB3 debug port. On a machine which supports USB3 debug
+   port, this file will be created. Reading this file will
+   show the state (disabled, enabled or configured) of the
+   debug port. On a machine that doesn't support USB3 debug
+   port, this file doesn't exist.
+
+   The state of a debug port could be:
+   1) disabled: The debug port is not enabled and the root
+   port has been switched to xHCI host as a normal
+   root port.
+   2) enabled: The debug port is enabled. The debug port
+   has been assigned to debug capability. The debug
+   capability is able to handle the control requests
+   defined in USB3 spec.
+   3) configured: The debug port has been enumerated by the
+   debug host as a debug device. The debug port is
+   in use now.
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index e7558ab..810c304 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -12,7 +12,7 @@ fhci-$(CONFIG_FHCI_DEBUG) += fhci-dbg.o
 
 xhci-hcd-y := xhci.o xhci-mem.o
 xhci-hcd-y += xhci-ring.o xhci-hub.o xhci-dbg.o
-xhci-hcd-y += xhci-trace.o
+xhci-hcd-y += xhci-trace.o xhci-sysfs.o
 
 xhci-plat-hcd-y := xhci-plat.o
 ifneq ($(CONFIG_USB_XHCI_MVEBU), )
diff --git a/drivers/usb/host/xhci-ext-caps.h b/drivers/usb/host/xhci-ext-caps.h
index 9fe3225..12c87e5 100644
--- a/drivers/usb/host/xhci-ext-caps.h
+++ b/drivers/usb/host/xhci-ext-caps.h
@@ -49,8 +49,15 @@
 #define XHCI_EXT_CAPS_PM   3
 #define XHCI_EXT_CAPS_VIRT 4
 #define XHCI_EXT_CAPS_ROUTE5
-/* IDs 6-9 reserved */
+#define XHCI_EXT_CAPS_LOCALMEM 6
+/* IDs 7-9 reserved */
 #define XHCI_EXT_CAPS_DEBUG10
+/* IDs 192-255 vendor specific */
+#define XHCI_EXT_CAPS_VEN_START192
+#define XHCI_EXT_CAPS_VEN_END  255
+#define XHCI_EXT_CAPS_VENDOR(p)(((p) >= XHCI_EXT_CAPS_VEN_START) && \
+   ((p) <= XHCI_EXT_CAPS_VEN_END))
+#define XHCI_EXT_MAX_CAPID XHCI_EXT_CAPS_VEN_END
 /* USB Legacy Support Capability - section 7.1.1 */
 #define XHCI_HC_BIOS_OWNED (1 << 16)
 #define XHCI_HC_OS_OWNED   (1 << 24)
@@ -73,6 +80,11 @@
 #define XHCI_HLC   (1 << 19)
 #define XHCI_BLC   (1 << 20)
 
+/* Debug capability - section 7.6.8 */
+#define XHCI_DBC_DCCTRL0x20
+#define XHCI_DBC_DCCTRL_DCR(1 << 0)
+#defineXHCI_DBC_DCCTRL_DCE (1 << 31)
+
 /* command register values to disable interrupts and halt the HC */
 /* start/stop HC execution - do not write unless HC is halted*/
 #define XHCI_CMD_RUN   (1 << 0)
diff --git a/drivers/usb/host/xhci-sysfs.c b/drivers/usb/host/xhci-sysfs.c
new file mode 100644
index 000..0192ac4
--- /dev/null
+++ b/drivers/usb/host/xhci-sysfs.c
@@ -0,0 +1,100 @@
+/*
+ * sysfs interface for xHCI host controller driver
+ *
+ * Copyright (C) 2015 Intel Corp.
+ *
+ * Author: Lu Baolu 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include 
+
+#include "xhci.h"
+
+/*
+ * Return the register offset of a extended capability specified
+ * by @cap_id. Return 0 if @cap_id capabi

Re: [PATCH V2 2/3] dmaselftest: add memcpy selftest support functions

[Andy Shevchenko]

On Tue, Nov 3, 2015 at 9:44 AM, Dan Williams  wrote:
> On Mon, Nov 2, 2015 at 10:30 PM, Vinod Koul  wrote:
>> On Mon, Nov 02, 2015 at 11:18:37PM -0500, Sinan Kaya wrote:
>>> On 11/2/2015 11:15 PM, Vinod Koul wrote:
>>> >On Mon, Nov 02, 2015 at 01:07:38AM -0500, Sinan Kaya wrote:


>>> This one; on the other hand, is selftest to verify hardware is
>>> working as expected during power up.

I prefer to have such nice case by run time parameter (let's say
common to all DMA Engine drivers)

>> We can have common code which is used for dmatest as well as selftest. I do
>> not want to see same code duplicated..

First thought was to merge this to dmatest, however, some DMA
controllers doesn't have a memcpy capability.

How would we test them?

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

[PATCH v3 1/2] watchdog: add WDIOC_SETPRETIMEOUT and WDIOC_GETPRETIMEOUT

[Robin Gong]

Since the watchdog common framework centrialize the IOCTL interfaces of
device driver now, the SETPRETIMEOUT and GETPRETIMEOUT need to be added
in the common code.

Signed-off-by: Robin Gong 
---
 Documentation/watchdog/watchdog-kernel-api.txt | 12 +
 drivers/watchdog/watchdog_dev.c| 37 ++
 include/linux/watchdog.h   | 11 
 3 files changed, 60 insertions(+)

diff --git a/Documentation/watchdog/watchdog-kernel-api.txt 
b/Documentation/watchdog/watchdog-kernel-api.txt
index d8b0d33..20aa841 100644
--- a/Documentation/watchdog/watchdog-kernel-api.txt
+++ b/Documentation/watchdog/watchdog-kernel-api.txt
@@ -51,6 +51,7 @@ struct watchdog_device {
const struct watchdog_ops *ops;
unsigned int bootstatus;
unsigned int timeout;
+   unsigned int pretimeout;
unsigned int min_timeout;
unsigned int max_timeout;
void *driver_data;
@@ -73,6 +74,7 @@ It contains following fields:
   additional information about the watchdog timer itself. (Like it's unique 
name)
 * ops: a pointer to the list of watchdog operations that the watchdog supports.
 * timeout: the watchdog timer's timeout value (in seconds).
+* pretimeout:  The watchdog devices pre_timeout value.
 * min_timeout: the watchdog timer's minimum timeout value (in seconds).
 * max_timeout: the watchdog timer's maximum timeout value (in seconds).
 * bootstatus: status of the device after booting (reported with watchdog
@@ -99,6 +101,7 @@ struct watchdog_ops {
int (*ping)(struct watchdog_device *);
unsigned int (*status)(struct watchdog_device *);
int (*set_timeout)(struct watchdog_device *, unsigned int);
+   int (*set_pretimeout)(struct watchdog_device *, unsigned int);
unsigned int (*get_timeleft)(struct watchdog_device *);
void (*ref)(struct watchdog_device *);
void (*unref)(struct watchdog_device *);
@@ -163,6 +166,15 @@ they are supported. These optional routines/operations are:
   because the watchdog does not necessarily has a 1 second resolution).
   (Note: the WDIOF_SETTIMEOUT needs to be set in the options field of the
   watchdog's info structure).
+* set_pretimeout: this routine check and changes the pre_timeout value of
+  the watchdog, because some watchdog device can trigger the pre_timeout
+  interrupt before watchdog timeout event happened, so that we have chance
+  to save some critical information or something else before watchdog
+  triggered. The pre_timeout value means the number of seconds before
+  watchdog timeout.It returns 0 on success, -EINVAL for "parameter out
+  of range" and and -EIO for "could not write value to the watchdog".
+  (Note: the WDIOF_SETPRETIMEOUT needs to be set in the options field of the
+  watchdog's info structure).
 * get_timeleft: this routines returns the time that's left before a reset.
 * ref: the operation that calls kref_get on the kref of a dynamically
   allocated watchdog_device struct.
diff --git a/drivers/watchdog/watchdog_dev.c b/drivers/watchdog/watchdog_dev.c
index 6aaefba..f4a02e5 100644
--- a/drivers/watchdog/watchdog_dev.c
+++ b/drivers/watchdog/watchdog_dev.c
@@ -218,6 +218,37 @@ out_timeout:
 }
 
 /*
+ * watchdog_set_pretimeout: set the watchdog timer pretimeout
+ * @wddev: the watchdog device to set the timeout for
+ * @timeout: pretimeout to set in seconds
+ */
+
+static int watchdog_set_pretimeout(struct watchdog_device *wddev,
+  unsigned int timeout)
+{
+   int err;
+
+   if (!wddev->ops->set_pretimeout ||
+   !(wddev->info->options & WDIOF_PRETIMEOUT))
+   return -EOPNOTSUPP;
+   if (watchdog_pretimeout_invalid(wddev, timeout))
+   return -EINVAL;
+
+   mutex_lock(&wddev->lock);
+
+   if (test_bit(WDOG_UNREGISTERED, &wddev->status)) {
+   err = -ENODEV;
+   goto out_timeout;
+   }
+
+   err = wddev->ops->set_pretimeout(wddev, timeout);
+
+out_timeout:
+   mutex_unlock(&wddev->lock);
+   return err;
+}
+
+/*
  * watchdog_get_timeleft: wrapper to get the time left before a reboot
  * @wddev: the watchdog device to get the remaining time from
  * @timeleft: the time that's left
@@ -393,6 +424,12 @@ static long watchdog_ioctl(struct file *file, unsigned int 
cmd,
if (err)
return err;
return put_user(val, p);
+   case WDIOC_SETPRETIMEOUT:
+   if (get_user(val, p))
+   return -EFAULT;
+   return watchdog_set_pretimeout(wdd, val);
+   case WDIOC_GETPRETIMEOUT:
+   return put_user(wdd->pretimeout, p);
default:
return -ENOTTY;
}
diff --git a/include/linux/watchdog.h b/include/linux/watchdog.h
index d74a0e9..281b949 100644
--- a/include/linux/watchdog.h
+++ b/include/linux/watchdog.h
@@ -25,6 +25,7 @@ struct watchdog_device;
  * @pi

Re: [PATCH RESEND 00/16] Support TI LMU devices

[Lee Jones]

On Tue, 03 Nov 2015, Kim, Milo wrote:

> Hi Lee,
> 
> On 11/2/2015 6:00 PM, Lee Jones wrote:
> >Is it just me, or have you missed lots of people off Cc?
> 
> Ah, that's what I was hesitating...
> What is the best way to submit MFD code patches? Cc for all people
> from get_maintainer.pl?

As this is a 0th patch of a set which touches many different
subsystems, I suggest that you should have Cc'ed all of the
Maintainers of the subsystems you changed.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RESEND 00/16] Support TI LMU devices

[Lee Jones]

On Tue, 03 Nov 2015, Kim, Milo wrote:

> Hi Lee,
> 
> On 11/2/2015 5:59 PM, Lee Jones wrote:
> >>  drivers/video/backlight/Kconfig|  62 ++
> >>>  drivers/video/backlight/Makefile   |   7 +
> >>>  drivers/video/backlight/lm3532_bl.c| 183 +
> >>>  drivers/video/backlight/lm3631_bl.c| 129 
> >>>  drivers/video/backlight/lm3632_bl.c| 125 
> >>>  drivers/video/backlight/lm3633_bl.c| 210 ++
> >>>  drivers/video/backlight/lm3695_bl.c|  91 +++
> >>>  drivers/video/backlight/lm3697_bl.c| 187 +
> >>>  drivers/video/backlight/ti-lmu-backlight.c | 429 
> >>>  drivers/video/backlight/ti-lmu-backlight.h | 152 +
> >How different are all of these drivers?
> >
> >Can you create one driver that supports them all instead?
> >
> 
> Thanks for your suggestion.
> 
> 'ti-lmu-backlight' is the common part of lm_bl drivers. And each
> lmxxx_bl has its own operation functions by using ti_lmu_bl_ops.
> I've tried to make consolidated driver but it contained too much
> device specific code in one file. So I prefer simple drivers
> structure - 'common part' and 'device specific operations'.
> It would be appreciated if you could introduce better idea.

I wish to avoid having to apply the patches to conduct my own analysis
of the files, as I am severely restricted on time.  Can you tell me how
much duplicated code there is between the files?  How many lines would
be saved by supporting all of the lm* drivers in a single file?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v3 2/2] watchdog: imx2_wdt: add set_pretimeout interface

[Robin Gong]

Enable set_pretimeout interface and trigger the pretimeout interrupt before
watchdog timeout event happen.

Signed-off-by: Robin Gong 
---
 drivers/watchdog/imx2_wdt.c | 58 -
 1 file changed, 57 insertions(+), 1 deletion(-)

diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
index 0bb1a1d..06631cf 100644
--- a/drivers/watchdog/imx2_wdt.c
+++ b/drivers/watchdog/imx2_wdt.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -52,12 +53,18 @@
 #define IMX2_WDT_WRSR  0x04/* Reset Status Register */
 #define IMX2_WDT_WRSR_TOUT (1 << 1)/* -> Reset due to Timeout */
 
+#define IMX2_WDT_WICR  0x06/*Interrupt Control Register*/
+#define IMX2_WDT_WICR_WIE  (1 << 15)   /* -> Interrupt Enable */
+#define IMX2_WDT_WICR_WTIS (1 << 14)   /* -> Interrupt Status */
+#define IMX2_WDT_WICR_WICT 0xFF/* Watchdog Interrupt Timeout */
+
 #define IMX2_WDT_WMCR  0x08/* Misc Register */
 
 #define IMX2_WDT_MAX_TIME  128
 #define IMX2_WDT_DEFAULT_TIME  60  /* in seconds */
 
 #define WDOG_SEC_TO_COUNT(s)   ((s * 2 - 1) << 8)
+#define WDOG_SEC_TO_PRECOUNT(s)((s) * 2)   /* set WDOG pre timeout 
count*/
 
 struct imx2_wdt_device {
struct clk *clk;
@@ -80,7 +87,8 @@ MODULE_PARM_DESC(timeout, "Watchdog timeout in seconds 
(default="
 
 static const struct watchdog_info imx2_wdt_info = {
.identity = "imx2+ watchdog",
-   .options = WDIOF_KEEPALIVEPING | WDIOF_SETTIMEOUT | WDIOF_MAGICCLOSE,
+   .options = WDIOF_KEEPALIVEPING | WDIOF_SETTIMEOUT | WDIOF_MAGICCLOSE
+  | WDIOF_PRETIMEOUT,
 };
 
 static int imx2_restart_handler(struct notifier_block *this, unsigned long 
mode,
@@ -207,12 +215,49 @@ static inline void imx2_wdt_ping_if_active(struct 
watchdog_device *wdog)
}
 }
 
+static int imx2_wdt_set_pretimeout(struct watchdog_device *wdog,
+  unsigned int new_timeout)
+{
+   struct imx2_wdt_device *wdev = watchdog_get_drvdata(wdog);
+   u32 val;
+
+   regmap_read(wdev->regmap, IMX2_WDT_WICR, &val);
+   /* set the new pre-timeout value in the WSR */
+   val &= ~IMX2_WDT_WICR_WICT;
+   val |= WDOG_SEC_TO_PRECOUNT(new_timeout);
+
+   regmap_write(wdev->regmap, IMX2_WDT_WICR, val | IMX2_WDT_WICR_WIE);
+
+   wdog->pretimeout = new_timeout;
+
+   return 0;
+}
+
+static irqreturn_t imx2_wdt_isr(int irq, void *dev_id)
+{
+   struct platform_device *pdev = dev_id;
+   struct watchdog_device *wdog = platform_get_drvdata(pdev);
+   struct imx2_wdt_device *wdev = watchdog_get_drvdata(wdog);
+   u32 val;
+
+   regmap_read(wdev->regmap, IMX2_WDT_WICR, &val);
+   if (val & IMX2_WDT_WICR_WTIS) {
+   /*clear interrupt status bit*/
+   regmap_write(wdev->regmap, IMX2_WDT_WICR, val);
+   panic("pre-timeout:%d, %d seconds remained\n", wdog->pretimeout,
+ wdog->timeout - wdog->pretimeout);
+   }
+
+   return IRQ_HANDLED;
+}
+
 static const struct watchdog_ops imx2_wdt_ops = {
.owner = THIS_MODULE,
.start = imx2_wdt_start,
.stop = imx2_wdt_stop,
.ping = imx2_wdt_ping,
.set_timeout = imx2_wdt_set_timeout,
+   .set_pretimeout = imx2_wdt_set_pretimeout,
 };
 
 static const struct regmap_config imx2_wdt_regmap_config = {
@@ -229,6 +274,7 @@ static int __init imx2_wdt_probe(struct platform_device 
*pdev)
struct resource *res;
void __iomem *base;
int ret;
+   int irq;
u32 val;
 
wdev = devm_kzalloc(&pdev->dev, sizeof(*wdev), GFP_KERNEL);
@@ -294,6 +340,16 @@ static int __init imx2_wdt_probe(struct platform_device 
*pdev)
goto disable_clk;
}
 
+   irq = platform_get_irq(pdev, 0);
+   if (irq > 0) {
+   ret = devm_request_irq(&pdev->dev, irq, imx2_wdt_isr, 0,
+  dev_name(&pdev->dev), pdev);
+   if (ret) {
+   dev_err(&pdev->dev, "can't get irq %d\n", irq);
+   goto disable_clk;
+   }
+   }
+
wdev->restart_handler.notifier_call = imx2_restart_handler;
wdev->restart_handler.priority = 128;
ret = register_restart_handler(&wdev->restart_handler);
-- 
1.9.1

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

Re: [PATCH v2 1/4] clocksource: rockchip: Make the driver more compatible

[Daniel Lezcano]

On 11/03/2015 03:00 AM, Caesar Wang wrote:

Daniel,

在 2015年11月03日 01:28, Daniel Lezcano 写道:

On 10/31/2015 12:47 AM, Heiko Stuebner wrote:

Hi Daniel,

Am Freitag, 30. Oktober 2015, 11:42:29 schrieb Daniel Lezcano:

On 10/30/2015 04:43 AM, Caesar Wang wrote:

Hi Daniel,

在 2015年10月01日 03:14, Heiko Stübner 写道:

Hi Daniel,

Am Dienstag, 29. September 2015, 06:18:03 schrieb Daniel Lezcano:

On 09/25/2015 04:14 AM, Caesar Wang wrote:

Build the arm64 SoCs (e.g.: RK3368) on Rockchip platform,
There are some failure with build up on timer driver for rockchip.

Says:
/tmp/ccdAnNy5.s:47: Error: missing immediate expression at  operand
1 --
`dsb`
...

The problem was different semantics of dsb on btw arm32 and arm64,
Here we can convert the dsb with insteading of dsb(sy).The "sy"
param
is the default which you are allow to omit, so on arm32 dsb()and
dsb(sy)
are the same.

Signed-off-by: Caesar Wang 

Acked-by: Daniel Lezcano 

as you have "just" Acked these patches, I guess you are expecting
them
to go
through the same tree as the devicetree changes, right?


I'm wonder if someone will apply this series patchs but the wait.:-)
In fact, I'm no sure that the Acked is really meaning.:-


Yes, by acking the patch I say I am ok with it and I agree it can go
through another tree.


although I guess the two clocksource changes could very well just go
through your tree. dsb() -> dsb(sy) is supposed to be equal and the
second
one is just cosmetics.  The Kconfig and dts changes need to wait in
any case
for 4.5 ... but I guess that may be true for the clocksource changes
as well?


Heiko, Caesar,

I am wondering if the dsb() is really necessary. Is it possible you
test the timer by removing this instruction ? Otherwise I will have to
setup my board again and it will take awhile.



As the @Arnd suggestion,

That's seem ok for me.
Although the writel_relaxed() and writel() a bit different  with DSB()
and L2's sync.

Do I need send the patch v3?  I will test that on my board.

I'm no sure that why the clocksource driver didn't use the
writel_relaxed() to work.
Okay, I think we should according to the suggestion or required.


I think the patch is trivial enough I can do the change myself if you 
test the change on your side. But it would be a good practice to send 
the patch you have tested. Up to you ;)


Thanks !

  -- Daniel


--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

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

Re: [PATCH v2 4/4] ocfs2: check/fix inode block for online file check

[Junxiao Bi]

On 11/03/2015 04:15 PM, Gang He wrote:
> Hello Junxiao,
> 
> See my comments inline.
> 
> 

>> Hi Gang,
>>
>> This is not like a right patch.
>> First, online file check only checks inode's block number, valid flag,
>> fs generation value, and meta ecc. I never see a real corruption
>> happened only on this field, if these fields are corrupted, that means
>> something bad may happen on other place. So fix this field may not help
>> and even cause corruption more hard.
> This online file check/fix feature is used to check/fix some light file meta 
> block corruption, instead of turning a file system off and using fsck.ocfs2.
What's light meta block corruption? Do you have a case about it?
> e.g. meta ecc error, we really need not to use fsck.ocfs2. 
> of course, this feature does not replace fsck.ocfs2 and touch some 
> complicated meta block problems, if there is some potential problem in some 
> areas, we can discuss them one by one.
> 
> 
> 
>> Second, the repair way is wrong. In
>> ocfs2_filecheck_repair_inode_block(), if these fields in disk don't
>> match the ones in memory, the ones in memory are used to update the disk
>> fields. The question is how do you know these field in memory are
>> right(they may be the real corrupted ones)?
> Here, if the inode block was corrupted, the file system is not able to load 
> it into the memory.
How do you know inode block corrupted? If bh for inode block is
overwritten, i mean bh corrupted, the repair will corrupted a good inode
block.

Thanks,
Junxiao.

> ocfs2_filecheck_repair_inode_block() will able to load it into the memory, 
> since it try to fix these light-level problem before loading.
> if the fix is OK, the changed meta-block can pass the block-validate function 
> and load into the memory as a inode object.
> Since the file system is under a cluster environment, we have to use some 
> existing function and code path to keep these block operation under a cluster 
> lock.
> 
> 
> Thanks
> Gang
> 
>>
>> Thanks,
>> Junxiao.
>> On 10/28/2015 02:26 PM, Gang He wrote:
>>> +static int ocfs2_filecheck_repair_inode_block(struct super_block *sb,
>>> +  struct buffer_head *bh)
>>> +{
>>> +   int rc;
>>> +   int changed = 0;
>>> +   struct ocfs2_dinode *di = (struct ocfs2_dinode *)bh->b_data;
>>> +
>>> +   rc = ocfs2_filecheck_validate_inode_block(sb, bh);
>>> +   /* Can't fix invalid inode block */
>>> +   if (!rc || rc == -OCFS2_FILECHECK_ERR_INVALIDINO)
>>> +   return rc;
>>> +
>>> +   trace_ocfs2_filecheck_repair_inode_block(
>>> +   (unsigned long long)bh->b_blocknr);
>>> +
>>> +   if (ocfs2_is_hard_readonly(OCFS2_SB(sb)) ||
>>> +   ocfs2_is_soft_readonly(OCFS2_SB(sb))) {
>>> +   mlog(ML_ERROR,
>>> +   "Filecheck: try to repair dinode #%llu on readonly 
>>> filesystem\n",
>>> +   (unsigned long long)bh->b_blocknr);
>>> +   return -OCFS2_FILECHECK_ERR_READONLY;
>>> +   }
>>> +
>>> +   if (le64_to_cpu(di->i_blkno) != bh->b_blocknr) {
>>> +   di->i_blkno = cpu_to_le64(bh->b_blocknr);
>>> +   changed = 1;
>>> +   mlog(ML_ERROR,
>>> +   "Filecheck: reset dinode #%llu: i_blkno to %llu\n",
>>> +   (unsigned long long)bh->b_blocknr,
>>> +   (unsigned long long)le64_to_cpu(di->i_blkno));
>>> +   }
>>> +
>>> +   if (!(di->i_flags & cpu_to_le32(OCFS2_VALID_FL))) {
>>> +   di->i_flags |= cpu_to_le32(OCFS2_VALID_FL);
>>> +   changed = 1;
>>> +   mlog(ML_ERROR,
>>> +   "Filecheck: reset dinode #%llu: OCFS2_VALID_FL is 
>>> set\n",
>>> +   (unsigned long long)bh->b_blocknr);
>>> +   }
>>> +
>>> +   if (le32_to_cpu(di->i_fs_generation) !=
>>> +   OCFS2_SB(sb)->fs_generation) {
>>> +   di->i_fs_generation = cpu_to_le32(OCFS2_SB(sb)->fs_generation);
>>> +   changed = 1;
>>> +   mlog(ML_ERROR,
>>> +   "Filecheck: reset dinode #%llu: fs_generation to %u\n",
>>> +   (unsigned long long)bh->b_blocknr,
>>> +   le32_to_cpu(di->i_fs_generation));
>>> +   }
>>> +
>>> +   if (changed ||
>>> +   ocfs2_validate_meta_ecc(sb, bh->b_data, &di->i_check)) {
>>> +   ocfs2_compute_meta_ecc(sb, bh->b_data, &di->i_check);
>>> +   mark_buffer_dirty(bh);
>>> +   mlog(ML_ERROR,
>>> +   "Filecheck: reset dinode #%llu: compute meta ecc\n",
>>> +   (unsigned long long)bh->b_blocknr);
>>> +   }
>>> +
>>> +   return 0;
>>> +}
> 

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

Re: [PATCH v2 2/4] ocfs2: sysfile interfaces for online file check

[Gang He]

Hi Junxiao,


>>> 
> Hi Gang,
> 
> On 11/03/2015 03:54 PM, Gang He wrote:
>> Hi Junxiao,
>> 
>> Thank for your reviewing.
>> Current design, we use a sysfile as a interface to check/fix a file (via 
> pass a ino number).
>> But, this operation is manually triggered by user, instead of automatically  
> fix in the kernel.
>> Why?
>> 1) we should let users make this decision, since some users do not want to 
> fix when encountering a file system corruption, maybe they want to keep the 
> file system unchanged for a further investigation.
> If user don't want this, they should not use error=continue option, let
> fs go after a corruption is very dangerous.
>> 2) frankly speaking, this feature will probably bring a second corruption if 
> there is some error in the code, I do not suggest to use automatically fix by 
> default in the first version.
> I think if this feature could bring more corruption, then this should be
> fixed first.
In theory, this feature will avoid bringing any second corruption after our 
detailed reviewing and discussion.
but, my means is that if there is any carelessness due to our experience 
limitation, it will probably bring a accident second corruption.
this is why, I do not suggest to use automatically fix by default in the kernel 
when a feature is firstly introduced.

> 
> Thanks,
> Junxiao
>> 3) in the future, if this feature is well proved, we can add a mount option 
> to make this automatically fix enabled.
>> 
>> 
>> Thanks
>> Gang
>>
>> 
>> 
>
>>> Hi Gang,
>>>
>>> I didn't see a need to add a sysfs file for the check and repair. This
>>> leaves a hard problem for customer to decide. How they decide whether
>>> they should repair the bad inode since this may cause corruption even
>>> harder?
>>> I think the error should be fixed by this feature automaticlly if repair
>>> helps, of course this can be done only when error=continue is enabled or
>>> add some mount option for it.
>>>
>>> Thanks,
>>> Junxiao.
>>>
>>> On 10/28/2015 02:25 PM, Gang He wrote:
 Implement online file check sysfile interfaces, e.g.
 how to create the related sysfile according to device name,
 how to display/handle file check request from the sysfile.

 Signed-off-by: Gang He 
 ---
  fs/ocfs2/Makefile|   3 +-
  fs/ocfs2/filecheck.c | 566 
>>> +++
  fs/ocfs2/filecheck.h |  48 +
  fs/ocfs2/inode.h |   3 +
  4 files changed, 619 insertions(+), 1 deletion(-)
  create mode 100644 fs/ocfs2/filecheck.c
  create mode 100644 fs/ocfs2/filecheck.h

 diff --git a/fs/ocfs2/Makefile b/fs/ocfs2/Makefile
 index ce210d4..e27e652 100644
 --- a/fs/ocfs2/Makefile
 +++ b/fs/ocfs2/Makefile
 @@ -41,7 +41,8 @@ ocfs2-objs := \
quota_local.o   \
quota_global.o  \
xattr.o \
 -  acl.o
 +  acl.o   \
 +  filecheck.o
  
  ocfs2_stackglue-objs := stackglue.o
  ocfs2_stack_o2cb-objs := stack_o2cb.o
 diff --git a/fs/ocfs2/filecheck.c b/fs/ocfs2/filecheck.c
 new file mode 100644
 index 000..f12ed1f
 --- /dev/null
 +++ b/fs/ocfs2/filecheck.c
 @@ -0,0 +1,566 @@
 +/* -*- mode: c; c-basic-offset: 8; -*-
 + * vim: noexpandtab sw=8 ts=8 sts=0:
 + *
 + * filecheck.c
 + *
 + * Code which implements online file check.
 + *
 + * Copyright (C) 2015 Novell.  All rights reserved.
 + *
 + * 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.
 + *
 + * This program is distributed in the hope that it will be useful,
 + * but WITHOUT ANY WARRANTY; without even the implied warranty of
 + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
 + * General Public License for more details.
 + */
 +
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +#include 
 +
 +#include "ocfs2.h"
 +#include "ocfs2_fs.h"
 +#include "stackglue.h"
 +#include "inode.h"
 +
 +#include "filecheck.h"
 +
 +
 +/* File check error strings,
 + * must correspond with error number in header file.
 + */
 +static const char * const ocfs2_filecheck_errs[] = {
 +  "SUCCESS",
 +  "FAILED",
 +  "INPROGRESS",
 +  "READONLY",
 +  "INVALIDINO",
 +  "BLOCKECC",
 +  "BLOCKNO",
 +  "VALIDFLAG",
 +  "GENERATION",
 +  "UNSUPPORTED"
 +};
 +
 +static DEFINE_SPINLOCK(ocfs2_filecheck_sysfs_lock);
 +static LIST_HEAD(ocfs2_filecheck_sysfs_list);
 +
 +struct ocfs2_filecheck {
 +  struct list_head fc_head;   /* File check entry list head */
 +  spinlock_t fc_lock;
 +  unsigned int fc_max;/* Maximum number of e

[PATCH v3 2/2] watchdog: imx2_wdt: add set_pretimeout interface

[Robin Gong]

Enable set_pretimeout interface and trigger the pretimeout interrupt before
watchdog timeout event happen.

Signed-off-by: Robin Gong 
---
 drivers/watchdog/imx2_wdt.c | 58 -
 1 file changed, 57 insertions(+), 1 deletion(-)

diff --git a/drivers/watchdog/imx2_wdt.c b/drivers/watchdog/imx2_wdt.c
index 0bb1a1d..06631cf 100644
--- a/drivers/watchdog/imx2_wdt.c
+++ b/drivers/watchdog/imx2_wdt.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -52,12 +53,18 @@
 #define IMX2_WDT_WRSR  0x04/* Reset Status Register */
 #define IMX2_WDT_WRSR_TOUT (1 << 1)/* -> Reset due to Timeout */
 
+#define IMX2_WDT_WICR  0x06/*Interrupt Control Register*/
+#define IMX2_WDT_WICR_WIE  (1 << 15)   /* -> Interrupt Enable */
+#define IMX2_WDT_WICR_WTIS (1 << 14)   /* -> Interrupt Status */
+#define IMX2_WDT_WICR_WICT 0xFF/* Watchdog Interrupt Timeout */
+
 #define IMX2_WDT_WMCR  0x08/* Misc Register */
 
 #define IMX2_WDT_MAX_TIME  128
 #define IMX2_WDT_DEFAULT_TIME  60  /* in seconds */
 
 #define WDOG_SEC_TO_COUNT(s)   ((s * 2 - 1) << 8)
+#define WDOG_SEC_TO_PRECOUNT(s)((s) * 2)   /* set WDOG pre timeout 
count*/
 
 struct imx2_wdt_device {
struct clk *clk;
@@ -80,7 +87,8 @@ MODULE_PARM_DESC(timeout, "Watchdog timeout in seconds 
(default="
 
 static const struct watchdog_info imx2_wdt_info = {
.identity = "imx2+ watchdog",
-   .options = WDIOF_KEEPALIVEPING | WDIOF_SETTIMEOUT | WDIOF_MAGICCLOSE,
+   .options = WDIOF_KEEPALIVEPING | WDIOF_SETTIMEOUT | WDIOF_MAGICCLOSE
+  | WDIOF_PRETIMEOUT,
 };
 
 static int imx2_restart_handler(struct notifier_block *this, unsigned long 
mode,
@@ -207,12 +215,49 @@ static inline void imx2_wdt_ping_if_active(struct 
watchdog_device *wdog)
}
 }
 
+static int imx2_wdt_set_pretimeout(struct watchdog_device *wdog,
+  unsigned int new_timeout)
+{
+   struct imx2_wdt_device *wdev = watchdog_get_drvdata(wdog);
+   u32 val;
+
+   regmap_read(wdev->regmap, IMX2_WDT_WICR, &val);
+   /* set the new pre-timeout value in the WSR */
+   val &= ~IMX2_WDT_WICR_WICT;
+   val |= WDOG_SEC_TO_PRECOUNT(new_timeout);
+
+   regmap_write(wdev->regmap, IMX2_WDT_WICR, val | IMX2_WDT_WICR_WIE);
+
+   wdog->pretimeout = new_timeout;
+
+   return 0;
+}
+
+static irqreturn_t imx2_wdt_isr(int irq, void *dev_id)
+{
+   struct platform_device *pdev = dev_id;
+   struct watchdog_device *wdog = platform_get_drvdata(pdev);
+   struct imx2_wdt_device *wdev = watchdog_get_drvdata(wdog);
+   u32 val;
+
+   regmap_read(wdev->regmap, IMX2_WDT_WICR, &val);
+   if (val & IMX2_WDT_WICR_WTIS) {
+   /*clear interrupt status bit*/
+   regmap_write(wdev->regmap, IMX2_WDT_WICR, val);
+   panic("pre-timeout:%d, %d seconds remained\n", wdog->pretimeout,
+ wdog->timeout - wdog->pretimeout);
+   }
+
+   return IRQ_HANDLED;
+}
+
 static const struct watchdog_ops imx2_wdt_ops = {
.owner = THIS_MODULE,
.start = imx2_wdt_start,
.stop = imx2_wdt_stop,
.ping = imx2_wdt_ping,
.set_timeout = imx2_wdt_set_timeout,
+   .set_pretimeout = imx2_wdt_set_pretimeout,
 };
 
 static const struct regmap_config imx2_wdt_regmap_config = {
@@ -229,6 +274,7 @@ static int __init imx2_wdt_probe(struct platform_device 
*pdev)
struct resource *res;
void __iomem *base;
int ret;
+   int irq;
u32 val;
 
wdev = devm_kzalloc(&pdev->dev, sizeof(*wdev), GFP_KERNEL);
@@ -294,6 +340,16 @@ static int __init imx2_wdt_probe(struct platform_device 
*pdev)
goto disable_clk;
}
 
+   irq = platform_get_irq(pdev, 0);
+   if (irq > 0) {
+   ret = devm_request_irq(&pdev->dev, irq, imx2_wdt_isr, 0,
+  dev_name(&pdev->dev), pdev);
+   if (ret) {
+   dev_err(&pdev->dev, "can't get irq %d\n", irq);
+   goto disable_clk;
+   }
+   }
+
wdev->restart_handler.notifier_call = imx2_restart_handler;
wdev->restart_handler.priority = 128;
ret = register_restart_handler(&wdev->restart_handler);
-- 
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: [RESEND PATCH] ARM: errata: Workaround for Cortex-A12 erratum 818325

[Arnd Bergmann]

On Tuesday 03 November 2015 16:10:09 Caesar Wang wrote:
> 
> +   /* Cortex-A12 Errata */
> +   ldr r10, =0x0c0d@ Cortex-A12 primary part 
> number
> +   teq r0, r10
> +   bne 5f
> +#ifdef CONFIG_ARM_ERRATA_818325
> +   teq r6, #0x00   @ present in r0p0
> +   teqne   r6, #0x01   @ present in r0p1-00lac0-rc11
> +   mrceq   p15, 0, r10, c15, c0, 1 @ read diagnostic register
> +   orreq   r10, r10, #1 << 12  @ set bit #12
> +   mcreq   p15, 0, r10, c15, c0, 1 @ write diagnostic register
> +   isb
> +#endif
> /* Cortex-A15 Errata */
> 

Does this still build? You seem to have lost the '5:' label.

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

Re: [PATCH v2 2/5] mfd: ts4800-syscon: add driver for TS-4800 syscon

[Lee Jones]

On Tue, 03 Nov 2015, Lee Jones wrote:

> On Mon, 02 Nov 2015, Damien Riegel wrote:
> > On Mon, Nov 02, 2015 at 09:12:53AM +, Lee Jones wrote:
> > > [Cc'ing Arnd]
> > > 
> > > On Fri, 30 Oct 2015, Damien Riegel wrote:
> > > > On Fri, Oct 30, 2015 at 05:56:56PM +, Lee Jones wrote:
> > > > > On Thu, 29 Oct 2015, Damien Riegel wrote:
> > > > > 
> > > > > > Driver for TS-4800 syscon. These registers belong to a FPGA that is
> > > > > > memory mapped and are used for counters, enable various IPs in the 
> > > > > > FPGA,
> > > > > > control LEDs, control IOs, etc.
> > > > > > 
> > > > > > Currently, only the watchdog is handled.
> > > > > 
> > > > > Why do you require your own syscon driver?
> > > > > 
> > > > > What's wrong with the generic one?
> > > > > 
> > > > 
> > > > The generic one uses a regmap_config with reg_stride set to 4 and 
> > > > val_bits
> > > > to 32.
> > > > 
> > > > TS-4800 syscon registers are 16-bit wide and must be accessed with 16
> > > > bit read and writes:
> > > > http://wiki.embeddedarm.com/wiki/TS-4800#Syscon
> > > > 
> > > > I will address the other issues in the next version (split commit,
> > > > license issue, style, and superfluous remove).
> > > 
> > > The Syscon driver was written to be generic so that each
> > > vendor/platform didn't require their own incarnation.  How unique is
> > > the TS-4800?
> > > 
> > > Perhaps it might be better to supply a generic 16 bit Syscon for
> > > devices akin to the TS-4800?
> > 
> > The TS-4800 syscon could use a generic 16-bit syscon. There is nothing
> > specific that requires a driver besides that.
> > 
> > We could add some optional properties to the generic syscon node to
> > configure reg_bits, val_bits, and reg_stride (and pad_bits ?). Would
> > that be a good solution ?
> 
> Without looking at the ramifications of such an addition, the premise
> sounds good to me.  So long as the current behaviour remains the
> default.

Perhaps a "syscon-16bit" compatible might be in order?

> > > Arnd, any opinion on this?
> 

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 4/4] ocfs2: check/fix inode block for online file check

[Gang He]

>>> 
> On 11/03/2015 04:15 PM, Gang He wrote:
>> Hello Junxiao,
>> 
>> See my comments inline.
>> 
>> 
>
>>> Hi Gang,
>>>
>>> This is not like a right patch.
>>> First, online file check only checks inode's block number, valid flag,
>>> fs generation value, and meta ecc. I never see a real corruption
>>> happened only on this field, if these fields are corrupted, that means
>>> something bad may happen on other place. So fix this field may not help
>>> and even cause corruption more hard.
>> This online file check/fix feature is used to check/fix some light file meta 
> block corruption, instead of turning a file system off and using fsck.ocfs2.
> What's light meta block corruption? Do you have a case about it?
>> e.g. meta ecc error, we really need not to use fsck.ocfs2. 
>> of course, this feature does not replace fsck.ocfs2 and touch some 
> complicated meta block problems, if there is some potential problem in some 
> areas, we can discuss them one by one.
>> 
>> 
>> 
>>> Second, the repair way is wrong. In
>>> ocfs2_filecheck_repair_inode_block(), if these fields in disk don't
>>> match the ones in memory, the ones in memory are used to update the disk
>>> fields. The question is how do you know these field in memory are
>>> right(they may be the real corrupted ones)?
>> Here, if the inode block was corrupted, the file system is not able to load 
> it into the memory.
> How do you know inode block corrupted? If bh for inode block is
> overwritten, i mean bh corrupted, the repair will corrupted a good inode
> block.
You know, the meta block is only validated when the file system loads the block 
from disk to memory.
If the inode object is in the memory, we consider this inode block is OK.
If the inode is not loaded by the file system via the normal way, the file 
system will print a kernel error log to tell which ino is corrupted.
we will use  ocfs2_filecheck_repair_inode_block() function to fix the inode 
block before loading.

Thanks
Gang

> 
> Thanks,
> Junxiao.
> 
>> ocfs2_filecheck_repair_inode_block() will able to load it into the memory, 
> since it try to fix these light-level problem before loading.
>> if the fix is OK, the changed meta-block can pass the block-validate 
>> function 
> and load into the memory as a inode object.
>> Since the file system is under a cluster environment, we have to use some 
> existing function and code path to keep these block operation under a cluster 
> lock.
>> 
>> 
>> Thanks
>> Gang
>> 
>>>
>>> Thanks,
>>> Junxiao.
>>> On 10/28/2015 02:26 PM, Gang He wrote:
 +static int ocfs2_filecheck_repair_inode_block(struct super_block *sb,
 + struct buffer_head *bh)
 +{
 +  int rc;
 +  int changed = 0;
 +  struct ocfs2_dinode *di = (struct ocfs2_dinode *)bh->b_data;
 +
 +  rc = ocfs2_filecheck_validate_inode_block(sb, bh);
 +  /* Can't fix invalid inode block */
 +  if (!rc || rc == -OCFS2_FILECHECK_ERR_INVALIDINO)
 +  return rc;
 +
 +  trace_ocfs2_filecheck_repair_inode_block(
 +  (unsigned long long)bh->b_blocknr);
 +
 +  if (ocfs2_is_hard_readonly(OCFS2_SB(sb)) ||
 +  ocfs2_is_soft_readonly(OCFS2_SB(sb))) {
 +  mlog(ML_ERROR,
 +  "Filecheck: try to repair dinode #%llu on readonly 
 filesystem\n",
 +  (unsigned long long)bh->b_blocknr);
 +  return -OCFS2_FILECHECK_ERR_READONLY;
 +  }
 +
 +  if (le64_to_cpu(di->i_blkno) != bh->b_blocknr) {
 +  di->i_blkno = cpu_to_le64(bh->b_blocknr);
 +  changed = 1;
 +  mlog(ML_ERROR,
 +  "Filecheck: reset dinode #%llu: i_blkno to %llu\n",
 +  (unsigned long long)bh->b_blocknr,
 +  (unsigned long long)le64_to_cpu(di->i_blkno));
 +  }
 +
 +  if (!(di->i_flags & cpu_to_le32(OCFS2_VALID_FL))) {
 +  di->i_flags |= cpu_to_le32(OCFS2_VALID_FL);
 +  changed = 1;
 +  mlog(ML_ERROR,
 +  "Filecheck: reset dinode #%llu: OCFS2_VALID_FL is 
 set\n",
 +  (unsigned long long)bh->b_blocknr);
 +  }
 +
 +  if (le32_to_cpu(di->i_fs_generation) !=
 +  OCFS2_SB(sb)->fs_generation) {
 +  di->i_fs_generation = cpu_to_le32(OCFS2_SB(sb)->fs_generation);
 +  changed = 1;
 +  mlog(ML_ERROR,
 +  "Filecheck: reset dinode #%llu: fs_generation to %u\n",
 +  (unsigned long long)bh->b_blocknr,
 +  le32_to_cpu(di->i_fs_generation));
 +  }
 +
 +  if (changed ||
 +  ocfs2_validate_meta_ecc(sb, bh->b_data, &di->i_check)) {
 +  ocfs2_compute_meta_ecc(sb, bh->b_data, &di->i_check);
 +  mark_buffer_dirty(bh);
 +  mlog(ML_ERROR,
 +  "Filecheck: reset dinode #%llu: compute meta ecc\n",
 +   

Re: [PATCH v2 2/5] mfd: ts4800-syscon: add driver for TS-4800 syscon

[Arnd Bergmann]

On Tuesday 03 November 2015 08:39:23 Lee Jones wrote:
> On Tue, 03 Nov 2015, Lee Jones wrote:
> 
> > On Mon, 02 Nov 2015, Damien Riegel wrote:
> > > On Mon, Nov 02, 2015 at 09:12:53AM +, Lee Jones wrote:
> > > > [Cc'ing Arnd]
> > > > 
> > > > On Fri, 30 Oct 2015, Damien Riegel wrote:
> > > > > On Fri, Oct 30, 2015 at 05:56:56PM +, Lee Jones wrote:
> > > > > > On Thu, 29 Oct 2015, Damien Riegel wrote:
> > > > > > 
> > > > > > > Driver for TS-4800 syscon. These registers belong to a FPGA that 
> > > > > > > is
> > > > > > > memory mapped and are used for counters, enable various IPs in 
> > > > > > > the FPGA,
> > > > > > > control LEDs, control IOs, etc.
> > > > > > > 
> > > > > > > Currently, only the watchdog is handled.
> > > > > > 
> > > > > > Why do you require your own syscon driver?
> > > > > > 
> > > > > > What's wrong with the generic one?
> > > > > > 
> > > > > 
> > > > > The generic one uses a regmap_config with reg_stride set to 4 and 
> > > > > val_bits
> > > > > to 32.
> > > > > 
> > > > > TS-4800 syscon registers are 16-bit wide and must be accessed with 16
> > > > > bit read and writes:
> > > > > http://wiki.embeddedarm.com/wiki/TS-4800#Syscon
> > > > > 
> > > > > I will address the other issues in the next version (split commit,
> > > > > license issue, style, and superfluous remove).
> > > > 
> > > > The Syscon driver was written to be generic so that each
> > > > vendor/platform didn't require their own incarnation.  How unique is
> > > > the TS-4800?
> > > > 
> > > > Perhaps it might be better to supply a generic 16 bit Syscon for
> > > > devices akin to the TS-4800?
> > > 
> > > The TS-4800 syscon could use a generic 16-bit syscon. There is nothing
> > > specific that requires a driver besides that.
> > > 
> > > We could add some optional properties to the generic syscon node to
> > > configure reg_bits, val_bits, and reg_stride (and pad_bits ?). Would
> > > that be a good solution ?
> > 
> > Without looking at the ramifications of such an addition, the premise
> > sounds good to me.  So long as the current behaviour remains the
> > default.
> 
> Perhaps a "syscon-16bit" compatible might be in order?
> 
> 

I think a 'buswidth=<16>;' property in addition to 'compatible="syscon"'
is more in line with what other subsystems do.

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

Re: [PATCH v11 13/28] tracing: Add hist trigger support for pausing and continuing a trace

[Namhyung Kim]

On Thu, Oct 22, 2015 at 01:14:17PM -0500, Tom Zanussi wrote:
> Allow users to append 'pause' or 'continue' to an existing trigger in
> order to have it paused or to have a paused trace continue.
> 
> This expands the hist trigger syntax from this:
> # echo hist:keys=xxx:vals=yyy:sort=zzz.descending \
>   [ if filter] > event/trigger
> 
> to this:
> 
> # echo hist:keys=xxx:vals=yyy:sort=zzz.descending:pause or cont \
>   [ if filter] > event/trigger

What if 'cont' is used for a non-existing hist?  I think it should
fail with -ENOENT but it seems that it'd create a new hist trigger..

Thanks,
Namhyung


> 
> Signed-off-by: Tom Zanussi 
> Tested-by: Masami Hiramatsu 
> ---
>  kernel/trace/trace.c |  7 ++-
>  kernel/trace/trace_events_hist.c | 26 +++---
>  2 files changed, 29 insertions(+), 4 deletions(-)
> 
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index efa8d05..a223959 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -3802,6 +3802,7 @@ static const char readme_msg[] =
>   "\t[:values=   "\t[:sort=field1,field2,...]\n"
>   "\t[:size=#entries]\n"
> + "\t[:pause][:continue]\n"
>   "\t[if ]\n\n"
>   "\tWhen a matching event is hit, an entry is added to a hash\n"
>   "\ttable using the key(s) and value(s) named, and the value of a\n"
> @@ -3816,7 +3817,11 @@ static const char readme_msg[] =
>   "\tused to specify more or fewer than the default 2048 entries\n"
>   "\tfor the hashtable size.\n\n"
>   "\tReading the 'hist' file for the event will dump the hash\n"
> - "\ttable in its entirety to stdout."
> + "\ttable in its entirety to stdout.\n\n"
> + "\tThe 'pause' parameter can be used to pause an existing hist\n"
> + "\ttrigger or to start a hist trigger but not log any events\n"
> + "\tuntil told to do so.  'continue' can be used to start or\n"
> + "\trestart a paused hist trigger.\n\n"
>  #endif
>  ;
>  
> diff --git a/kernel/trace/trace_events_hist.c 
> b/kernel/trace/trace_events_hist.c
> index 4fc3136..8753c3b 100644
> --- a/kernel/trace/trace_events_hist.c
> +++ b/kernel/trace/trace_events_hist.c
> @@ -78,6 +78,8 @@ struct hist_trigger_attrs {
>   char*keys_str;
>   char*vals_str;
>   char*sort_key_str;
> + boolpause;
> + boolcont;
>   unsigned intmap_bits;
>  };
>  
> @@ -184,6 +186,11 @@ static struct hist_trigger_attrs 
> *parse_hist_trigger_attrs(char *trigger_str)
>   attrs->vals_str = kstrdup(str, GFP_KERNEL);
>   else if (!strncmp(str, "sort", strlen("sort")))
>   attrs->sort_key_str = kstrdup(str, GFP_KERNEL);
> + else if (!strncmp(str, "pause", strlen("pause")))
> + attrs->pause = true;
> + else if (!strncmp(str, "continue", strlen("continue")) ||
> +  !strncmp(str, "cont", strlen("cont")))
> + attrs->cont = true;
>   else if (!strncmp(str, "size", strlen("size"))) {
>   int map_bits = parse_map_size(str);
>  
> @@ -843,7 +850,10 @@ static int event_hist_trigger_print(struct seq_file *m,
>   if (data->filter_str)
>   seq_printf(m, " if %s", data->filter_str);
>  
> - seq_puts(m, " [active]");
> + if (data->paused)
> + seq_puts(m, " [paused]");
> + else
> + seq_puts(m, " [active]");
>  
>   seq_putc(m, '\n');
>  
> @@ -882,16 +892,25 @@ static int hist_register_trigger(char *glob, struct 
> event_trigger_ops *ops,
>struct event_trigger_data *data,
>struct trace_event_file *file)
>  {
> + struct hist_trigger_data *hist_data = data->private_data;
>   struct event_trigger_data *test;
>   int ret = 0;
>  
>   list_for_each_entry_rcu(test, &file->triggers, list) {
>   if (test->cmd_ops->trigger_type == ETT_EVENT_HIST) {
> - ret = -EEXIST;
> + if (hist_data->attrs->pause)
> + test->paused = true;
> + else if (hist_data->attrs->cont)
> + test->paused = false;
> + else
> + ret = -EEXIST;
>   goto out;
>   }
>   }
>  
> + if (hist_data->attrs->pause)
> + data->paused = true;
> +
>   if (data->ops->init) {
>   ret = data->ops->init(data->ops, data);
>   if (ret < 0)
> @@ -984,7 +1003,8 @@ static int event_hist_trigger_func(struct event_command 
> *cmd_ops,
>* triggers registered a failure too.
>*/
>   if (!ret) {
> - ret = -ENOENT;
> + if (!(attrs->pause || attrs->c

Re: [PATCH v3 2/4] perf callchain: Abstract callchain print function

[Jiri Olsa]

On Tue, Nov 03, 2015 at 04:18:29PM +0900, Namhyung Kim wrote:

SNIP

>   while (rb_node) {
> - double percent;
> -
>   chain = rb_entry(rb_node, struct callchain_node, rb_node);
> - percent = chain->hit * 100.0 / total_samples;
>  
> - ret = percent_color_fprintf(fp, "   %6.2f%%\n", 
> percent);
> + ret += fprintf(fp, "   ");
> + ret += callchain_node__fprintf_value(chain, fp, total_samples);
> + ret += fprintf(fp, "\n");
>   ret += __callchain__fprintf_flat(fp, chain, total_samples);
>   ret += fprintf(fp, "\n");
>   if (++entries_printed == callchain_param.print_limit)
> @@ -294,12 +294,11 @@ static size_t callchain__fprintf_folded(FILE *fp, 
> struct rb_root *tree,
>   struct rb_node *rb_node = rb_first(tree);
>  
>   while (rb_node) {
> - double percent;
>  
>   chain = rb_entry(rb_node, struct callchain_node, rb_node);
> - percent = chain->hit * 100.0 / total_samples;
>  
> - ret += fprintf(fp, "%.2f%% ", percent);
> + ret += callchain_node__fprintf_value(chain, fp, total_samples);
> + ret += fprintf(fp, " ");

hum, the callchain_node__fprintf_value gets hits as callchain_cumul_hits(node)
which is 'node->hit + node->children_hit'

while the replaced code took only 'chain->hit'

not sure now which one we actualy want here..

jirka

>   ret += __callchain__fprintf_folded(fp, chain);
>   ret += fprintf(fp, "\n");
>   if (++entries_printed == callchain_param.print_limit)
> diff --git a/tools/perf/util/callchain.c b/tools/perf/util/callchain.c
> index 08cb220ba5ea..44184d198855 100644
> --- a/tools/perf/util/callchain.c
> +++ b/tools/perf/util/callchain.c
> @@ -805,6 +805,31 @@ char *callchain_list__sym_name(struct callchain_list *cl,
>   return bf;
>  }
>  
> +char *callchain_node__sprintf_value(struct callchain_node *node,
> + char *bf, size_t bfsize, u64 total)
> +{
> + double percent = 0.0;
> + u64 cumul = callchain_cumul_hits(node);
> +
> + if (total)
> + percent = cumul * 100.0 / total;
> +
> + scnprintf(bf, bfsize, "%6.2f%%", percent);
> + return bf;
> +}
> +
> +int callchain_node__fprintf_value(struct callchain_node *node,
> +  FILE *fp, u64 total)
> +{
> + double percent = 0.0;
> + u64 cumul = callchain_cumul_hits(node);
> +
> + if (total)
> + percent = cumul * 100.0 / total;
> +
> + return percent_color_fprintf(fp, "%.2f%%", percent);
> +}

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

Re: [PATCH v2 2/5] mfd: ts4800-syscon: add driver for TS-4800 syscon

[Lee Jones]

On Mon, 02 Nov 2015, Damien Riegel wrote:
> On Mon, Nov 02, 2015 at 09:12:53AM +, Lee Jones wrote:
> > [Cc'ing Arnd]
> > 
> > On Fri, 30 Oct 2015, Damien Riegel wrote:
> > > On Fri, Oct 30, 2015 at 05:56:56PM +, Lee Jones wrote:
> > > > On Thu, 29 Oct 2015, Damien Riegel wrote:
> > > > 
> > > > > Driver for TS-4800 syscon. These registers belong to a FPGA that is
> > > > > memory mapped and are used for counters, enable various IPs in the 
> > > > > FPGA,
> > > > > control LEDs, control IOs, etc.
> > > > > 
> > > > > Currently, only the watchdog is handled.
> > > > 
> > > > Why do you require your own syscon driver?
> > > > 
> > > > What's wrong with the generic one?
> > > > 
> > > 
> > > The generic one uses a regmap_config with reg_stride set to 4 and val_bits
> > > to 32.
> > > 
> > > TS-4800 syscon registers are 16-bit wide and must be accessed with 16
> > > bit read and writes:
> > > http://wiki.embeddedarm.com/wiki/TS-4800#Syscon
> > > 
> > > I will address the other issues in the next version (split commit,
> > > license issue, style, and superfluous remove).
> > 
> > The Syscon driver was written to be generic so that each
> > vendor/platform didn't require their own incarnation.  How unique is
> > the TS-4800?
> > 
> > Perhaps it might be better to supply a generic 16 bit Syscon for
> > devices akin to the TS-4800?
> 
> The TS-4800 syscon could use a generic 16-bit syscon. There is nothing
> specific that requires a driver besides that.
> 
> We could add some optional properties to the generic syscon node to
> configure reg_bits, val_bits, and reg_stride (and pad_bits ?). Would
> that be a good solution ?

Without looking at the ramifications of such an addition, the premise
sounds good to me.  So long as the current behaviour remains the
default.

> > Arnd, any opinion on this?

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Resource leak in unshare

[Dmitry Vyukov]

On Mon, Nov 2, 2015 at 8:01 PM, Eric W. Biederman  wrote:
> Dmitry Vyukov  writes:
>
>> Hello,
>>
>> I am hitting the following warnings on
>> bcee19f424a0d8c26ecf2607b73c690802658b29 (4.3):
>
> Do you have any trace of the earlier failures?
>
> This appears to be something caused by an earlier failure (possibly
> whatever fails to allocate memory).  Having network devices present
> but being in the generic cleanup routines is wrong.
>
> If there is no additional information can you please rerun with the
> following change applied?  That should at least report which function is
> failing, and give us a good clue where to start debugging this.


So is it all fixed now? Or it is still clear how it can happen?
Eric (Dumazet), do you see how the WARNING can fire?
I don't have any logs at the moment, but I can run fuzzer for longer
to reproduce it again if necessary.



> diff --git a/net/core/net_namespace.c b/net/core/net_namespace.c
> index 2c2eb1b629b1..125c94af22b8 100644
> --- a/net/core/net_namespace.c
> +++ b/net/core/net_namespace.c
> @@ -292,6 +292,7 @@ out:
> return error;
>
>  out_undo:
> +   WARN(1, "net ops->init %pF returned with %d\n", ops->init, error);
> /* Walk through the list backwards calling the exit functions
>  * for the pernet modules whose init functions did not fail.
>  */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] clocksource: dw_apb_timer_of: support timer-based delay

[Arnd Bergmann]

On Tuesday 03 November 2015 14:59:40 Jisheng Zhang wrote:
> > On Monday 02 November 2015 11:03:34 Jisheng Zhang wrote:
> > > On Fri, 30 Oct 2015 13:42:01 +0100 Arnd Bergmann wrote:  
> > I'd be happier with a solution that keeps the DT describing the hardware
> > and not the way we expect Linux to use it, and instead has some heuristic
> > in the selection of the delay timer. At the moment, we purely base this
> > on the frequency, which as you say is suboptimal.
> > 
> > One possible way to improve this would be to add an optional 'latency'
> > property to the DT nodes (or the driver), and use a combination of latency
> > and resolution to make the decision.
> 
> Got it. Thanks for the suggestions. The 'latency' here seems a 'rating'
> similar as the one in clocksource. I will cook a series for review:
> 
> patch 1 to make register_current_timer_delay() aware of 'rating'
> 
> patch 2 to set rating of arch timer as 400
> 
> patch 3 to add timer based delay support to dw_apb_timer whose rating is 300

Ok. Just to make sure I got this right: your plan is to use the existing
'rating' setting as a primary indication, and fall back to comparing the
frequency if the rating is the same?

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

Re: [PATCH v11 14/28] tracing: Add hist trigger support for clearing a trace

[Namhyung Kim]

On Thu, Oct 22, 2015 at 01:14:18PM -0500, Tom Zanussi wrote:
> Allow users to append 'clear' to an existing trigger in order to have
> the hash table cleared.

Same as the previous comment: It'd be better not creating a new hist
if given hist doesn't exist.

Thanks,
Namhyung


> 
> This expands the hist trigger syntax from this:
> # echo hist:keys=xxx:vals=yyy:sort=zzz.descending:pause/cont \
>[ if filter] > event/trigger
> 
> to this:
> 
> # echo hist:keys=xxx:vals=yyy:sort=zzz.descending:pause/cont/clear \
>   [ if filter] > event/trigger
> 
> Signed-off-by: Tom Zanussi 
> Tested-by: Masami Hiramatsu 
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] usb: remove unnecessary CONFIG_PM dependency from USB_OTG

[Peter Chen]

On Thu, Oct 29, 2015 at 08:52:23AM -0500, Nathan Sullivan wrote:
> The USB OTG support currently depends on power management
> (CONFIG_PM) being enabled, but does not actually need it enabled.
> Remove this dependency.
> 
> Tested on Bay Trail hardware with dwc3 USB.
> 
> Signed-off-by: Nathan Sullivan 
> ---
>  drivers/usb/core/Kconfig |1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/usb/core/Kconfig b/drivers/usb/core/Kconfig
> index a99c89e..9c5cdf3 100644
> --- a/drivers/usb/core/Kconfig
> +++ b/drivers/usb/core/Kconfig
> @@ -43,7 +43,6 @@ config USB_DYNAMIC_MINORS
>  
>  config USB_OTG
>   bool "OTG support"
> - depends on PM
>   default n
>   help
> The most notable feature of USB OTG is support for a
> -- 
> 1.7.10.4
> 

Acked-by: Peter Chen 

-- 

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

[GIT PULL] procfs: Don't expose absolute kernel addresses via /proc/PID/stat

[Ingo Molnar]

Linus,

Please pull this single commit from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
core-debug-for-linus

   # HEAD: b2f73922d119686323f14fbbe46587f863852328 fs/proc, core/debug: Don't 
expose absolute kernel addresses via wchan

This fixes a wchan related information leak in /proc/PID/stat.

There's a bit of an ABI twist to it: instead of setting the wchan field to 0 
(which is our usual technique) we set it conditionally to a 0/1 flag to keep 
ABI 
compatibility with older procps versions that only fetches /proc/PID/wchan 
(symbolic names) if the absolute wchan address is nonzero.

 Thanks,

Ingo

-->
Ingo Molnar (1):
  fs/proc, core/debug: Don't expose absolute kernel addresses via wchan


 Documentation/filesystems/proc.txt |  5 +++--
 fs/proc/array.c| 16 ++--
 fs/proc/base.c |  9 +++--
 3 files changed, 20 insertions(+), 10 deletions(-)

diff --git a/Documentation/filesystems/proc.txt 
b/Documentation/filesystems/proc.txt
index d411ca63c8b6..3a9d65c912e7 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -140,7 +140,8 @@ Table 1-1: Process specific entries in /proc
  stat  Process status
  statm Process memory status information
  statusProcess status in human readable form
- wchan If CONFIG_KALLSYMS is set, a pre-decoded wchan
+ wchan Present with CONFIG_KALLSYMS=y: it shows the kernel function
+   symbol the task is blocked in - or "0" if not blocked.
  pagemap   Page table
  stack Report full stack trace, enable via CONFIG_STACKTRACE
  smaps a extension based on maps, showing the memory consumption of
@@ -310,7 +311,7 @@ Table 1-4: Contents of the stat files (as of 2.6.30-rc7)
   blocked   bitmap of blocked signals
   sigignbitmap of ignored signals
   sigcatch  bitmap of caught signals
-  wchan address where process went to sleep
+  0(place holder, used to be the wchan address, use 
/proc/PID/wchan instead)
   0 (place holder)
   0 (place holder)
   exit_signal   signal to send to parent thread on exit
diff --git a/fs/proc/array.c b/fs/proc/array.c
index f60f0121e331..eed2050db9be 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -375,7 +375,7 @@ int proc_pid_status(struct seq_file *m, struct 
pid_namespace *ns,
 static int do_task_stat(struct seq_file *m, struct pid_namespace *ns,
struct pid *pid, struct task_struct *task, int whole)
 {
-   unsigned long vsize, eip, esp, wchan = ~0UL;
+   unsigned long vsize, eip, esp, wchan = 0;
int priority, nice;
int tty_pgrp = -1, tty_nr = 0;
sigset_t sigign, sigcatch;
@@ -507,7 +507,19 @@ static int do_task_stat(struct seq_file *m, struct 
pid_namespace *ns,
seq_put_decimal_ull(m, ' ', task->blocked.sig[0] & 0x7fffUL);
seq_put_decimal_ull(m, ' ', sigign.sig[0] & 0x7fffUL);
seq_put_decimal_ull(m, ' ', sigcatch.sig[0] & 0x7fffUL);
-   seq_put_decimal_ull(m, ' ', wchan);
+
+   /*
+* We used to output the absolute kernel address, but that's an
+* information leak - so instead we show a 0/1 flag here, to signal
+* to user-space whether there's a wchan field in /proc/PID/wchan.
+*
+* This works with older implementations of procps as well.
+*/
+   if (wchan)
+   seq_puts(m, " 1");
+   else
+   seq_puts(m, " 0");
+
seq_put_decimal_ull(m, ' ', 0);
seq_put_decimal_ull(m, ' ', 0);
seq_put_decimal_ll(m, ' ', task->exit_signal);
diff --git a/fs/proc/base.c b/fs/proc/base.c
index b25eee4cead5..29595af32866 100644
--- a/fs/proc/base.c
+++ b/fs/proc/base.c
@@ -430,13 +430,10 @@ static int proc_pid_wchan(struct seq_file *m, struct 
pid_namespace *ns,
 
wchan = get_wchan(task);
 
-   if (lookup_symbol_name(wchan, symname) < 0) {
-   if (!ptrace_may_access(task, PTRACE_MODE_READ))
-   return 0;
-   seq_printf(m, "%lu", wchan);
-   } else {
+   if (wchan && ptrace_may_access(task, PTRACE_MODE_READ) && 
!lookup_symbol_name(wchan, symname))
seq_printf(m, "%s", symname);
-   }
+   else
+   seq_putc(m, '0');
 
return 0;
 }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 20/22] clocksource/drivers/exynos_mct: Fix Kconfig and add COMPILE_TEST option

[Daniel Lezcano]

On 11/03/2015 01:59 AM, Krzysztof Kozlowski wrote:

On 03.11.2015 09:30, Krzysztof Kozlowski wrote:

On 02.11.2015 21:56, Daniel Lezcano wrote:

Let the platform's Kconfig to select the clock instead of having a reverse
dependency from the driver to the platform options.


Selecting user-visible symbols is rather discouraged so why not
something like this:

-   def_bool y if ARCH_EXYNOS
-   depends on !ARM64
+   bool "Exynos multi core timer driver"
+   depends on ARCH_EXYNOS || (COMPILE_TEST && ARM)


Nope, that was wrong as we loose auto-select on Exynos. Instead:
-   def_bool y if ARCH_EXYNOS
-   depends on !ARM64
+   bool "Exynos multi core timer driver" if ARM
+   depends on ARCH_EXYNOS || COMPILE_TEST
+   default y if ARCH_EXYNOS

This way we avoid select (which is a reverse dependency for the driver),
have it auto-selectable and compile tested on arm.


I think you misunderstood the patch I sent.

It does two things:

1. Follow the thumb of rule of the current Kconfig format

   - The timer driver is selected by the platform (exynos in this case)
   - User can't select the driver in the menuconfig
   - There is no dependency on the platform except for compilation test

2. Add the COMPILE_TEST

   - User can select the driver for compilation testing. This is for 
allyesconfig when doing compilation test coverage (exynos timer could be 
compiled on other platform). As the delay code is not portable, we have 
to restrict the compilation on the ARM platform, this is why there is 
the dependency on ARM.


I am currently looking at splitting the delay code in order to prevent 
this restriction on this driver and some others drivers.




Add the COMPILE_TEST option for the compilation test coverage. Due to the
non portable 'delay' code, this driver is only compilable on ARM.

Signed-off-by: Daniel Lezcano 
---
  arch/arm/mach-exynos/Kconfig | 1 +
  drivers/clocksource/Kconfig  | 4 ++--
  2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 3a10f1a..ff10539 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -27,6 +27,7 @@ menuconfig ARCH_EXYNOS
select SRAM
select THERMAL
select MFD_SYSCON
+   select CLKSRC_EXYNOS_MCT
help
  Support for SAMSUNG EXYNOS SoCs (EXYNOS4/5)

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index 916c36d..d829cbe 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -213,8 +213,8 @@ config CLKSRC_METAG_GENERIC
  This option enables support for the Meta per-thread timers.

  config CLKSRC_EXYNOS_MCT
-   def_bool y if ARCH_EXYNOS
-   depends on !ARM64
+   bool "Exynos multi core timer driver" if COMPILE_TEST
+   depends on ARM
help
  Support for Multi Core Timer controller on Exynos SoCs.










--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v11 22/28] tracing: Add enable_hist/disable_hist triggers

[Namhyung Kim]

On Thu, Oct 22, 2015 at 01:14:26PM -0500, Tom Zanussi wrote:
> Similar to enable_event/disable_event triggers, these triggers enable
> and disable the aggregation of events into maps rather than enabling
> and disabling their writing into the trace buffer.
> 
> They can be used to automatically start and stop hist triggers based
> on a matching filter condition.
> 
> If there's a paused hist trigger on system:event, the following would
> start it when the filter condition was hit:
> 
>   # echo enable_hist:system:event [ if filter] > event/trigger
> 
> And the following would disable a running system:event hist trigger:
> 
>   # echo disable_hist:system:event [ if filter] > event/trigger

What about named hist triggers?  Maybe worth adding
"enable/disable_hist_name" too?

Thanks,
Namhyung


> 
> See Documentation/trace/events.txt for real examples.
> 
> Signed-off-by: Tom Zanussi 
> Tested-by: Masami Hiramatsu 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v1 1/4] Crypto: Crypto driver support aes/des/des3 for rk3288

[LABBE Corentin]

On Tue, Nov 03, 2015 at 01:52:05PM +0800, Zain Wang wrote:
> Crypto driver support cbc/ecb two chainmode, and aes/des/des3 three cipher
> mode.
> The names registered are:
> ecb(aes) cbc(aes) ecb(des) cbc(des) ecb(des3_ede) cbc(des3_ede)
> You can alloc tags above in your case.
> 
> And other algorithms and platforms will be added later on.
> 
> Signed-off-by: Zain Wang 
> ---
>  drivers/crypto/Kconfig |  11 +
>  drivers/crypto/Makefile|   1 +
>  drivers/crypto/rockchip/Makefile   |   3 +
>  drivers/crypto/rockchip/rk3288_crypto.c| 383 
>  drivers/crypto/rockchip/rk3288_crypto.h| 290 
>  drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c | 501 
> +
>  6 files changed, 1189 insertions(+)
>  create mode 100644 drivers/crypto/rockchip/Makefile
>  create mode 100644 drivers/crypto/rockchip/rk3288_crypto.c
>  create mode 100644 drivers/crypto/rockchip/rk3288_crypto.h
>  create mode 100644 drivers/crypto/rockchip/rk3288_crypto_ablkcipher.c
> 
> diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
> index 2569e04..d1e42cf 100644
> --- a/drivers/crypto/Kconfig
> +++ b/drivers/crypto/Kconfig
> @@ -498,4 +498,15 @@ config CRYPTO_DEV_SUN4I_SS
> To compile this driver as a module, choose M here: the module
> will be called sun4i-ss.
>  
> +config CRYPTO_DEV_ROCKCHIP
> + tristate "Rockchip's Cryptographic Engine driver"
> +
> + select CRYPTO_AES
> + select CRYPTO_DES
> + select CRYPTO_BLKCIPHER
> +
> + help
> +   This driver interfaces with the hardware crypto accelerator.
> +   Supporting cbc/ecb chainmode, and aes/des/des3_ede cipher mode.
> +
>  endif # CRYPTO_HW
> diff --git a/drivers/crypto/Makefile b/drivers/crypto/Makefile
> index c3ced6f..713de9d 100644
> --- a/drivers/crypto/Makefile
> +++ b/drivers/crypto/Makefile
> @@ -29,3 +29,4 @@ obj-$(CONFIG_CRYPTO_DEV_QAT) += qat/
>  obj-$(CONFIG_CRYPTO_DEV_QCE) += qce/
>  obj-$(CONFIG_CRYPTO_DEV_VMX) += vmx/
>  obj-$(CONFIG_CRYPTO_DEV_SUN4I_SS) += sunxi-ss/
> +obj-$(CONFIG_CRYPTO_DEV_ROCKCHIP) += rockchip/
> diff --git a/drivers/crypto/rockchip/Makefile 
> b/drivers/crypto/rockchip/Makefile
> new file mode 100644
> index 000..7051c6c
> --- /dev/null
> +++ b/drivers/crypto/rockchip/Makefile
> @@ -0,0 +1,3 @@
> +obj-$(CONFIG_CRYPTO_DEV_ROCKCHIP) += rk_crypto.o
> +rk_crypto-objs := rk3288_crypto.o \
> +   rk3288_crypto_ablkcipher.o \
> diff --git a/drivers/crypto/rockchip/rk3288_crypto.c 
> b/drivers/crypto/rockchip/rk3288_crypto.c
> new file mode 100644
> index 000..02830f2
> --- /dev/null
> +++ b/drivers/crypto/rockchip/rk3288_crypto.c
> @@ -0,0 +1,383 @@
> +/*
> + *Crypto acceleration support for Rockchip RK3288
> + *
> + * Copyright (c) 2015, Fuzhou Rockchip Electronics Co., Ltd
> + *
> + * Author: Zain Wang 
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms and conditions of the GNU General Public License,
> + * version 2, as published by the Free Software Foundation.
> + *
> + * Some ideas are from marvell-cesa.c and s5p-sss.c driver.
> + */
> +
> +#include "rk3288_crypto.h"
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +struct crypto_info_t *crypto_p;
> +
> +static int rk_crypto_enable_clk(struct crypto_info_t *dev)
> +{
> + int err;
> +
> + err = clk_prepare_enable(dev->sclk);
> + if (err) {
> + dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'sclk'\n",
> + __func__, __LINE__);
> + goto err_return;
> + }
> + err = clk_prepare_enable(dev->aclk);
> + if (err) {
> + dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'aclk'\n",
> + __func__, __LINE__);
> + goto err_aclk;
> + }
> + err = clk_prepare_enable(dev->hclk);
> + if (err) {
> + dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'hclk'\n",
> + __func__, __LINE__);
> + goto err_hclk;
> + }
> +
> + err = clk_prepare_enable(dev->dmaclk);
> + if (err) {
> + dev_err(dev->dev, "[%s:%d], Couldn't enable clock 'dmaclk'\n",
> + __func__, __LINE__);
> + goto err_dmaclk;
> + }
> + return err;
> +err_dmaclk:
> + clk_disable_unprepare(dev->hclk);
> +err_hclk:
> + clk_disable_unprepare(dev->aclk);
> +err_aclk:
> + clk_disable_unprepare(dev->sclk);
> +err_return:
> + return err;
> +}
> +
> +static void rk_crypto_disable_clk(struct crypto_info_t *dev)
> +{
> + clk_disable_unprepare(dev->dmaclk);
> + clk_disable_unprepare(dev->hclk);
> + clk_disable_unprepare(dev->aclk);
> + clk_disable_unprepare(dev->sclk);
> +}
> +
> +static int check_alignment(struct scatterlist *sg_src,
> +  

Re: Unreliable register being read in max310x UART driver

[Alexander Shiyan]

Hello.

> Понедельник,  2 ноября 2015, 10:24 -05:00 от Alexander Shi 
> :
> 
> Hello all,
>  
> The datasheet for MAX3107 UART ( 
> http://datasheets.maximintegrated.com/en/ds/MAX3107.pdf ) was updated in 
> February 2015 with a notice that the RxFIFOLvl register may be inaccurate if 
> read while being updated. The respective max310x.c driver in the kernel 
> actively makes use of the RxFIFOLvl register, but has not been updated since 
> the notice was posted. Does anyone have a workaround to this bug?
>  
> The notice was phrased as follows:
> “The RxFIFOLvl register represents the current number of words in the receive 
> FIFO whenever the receive UART is idle. When the receive UART actively 
> receives characters, the value in this register can sometimes be inaccurate 
> if this register is read at the same time that the receive UART updates the 
> receive FIFO. To manage the receive FIFO even when the receive UART is 
> active, do not use this register to determine receive FIFO state. Use the 
> RFIFOEmptyInt bit, the RxTrgInt bit, and the RTimeOut bit instead.”
>  
> Thanks,
> Alex

On my opinion this should not be a problem.
The RX interrupt will be triggered once again if we lost RX level value.
Anyway, you can add one check after reading rxfifolvl register:
  if (!(ists & MAX310X_IRQ_RXEMPTY_BIT))
rxlen = 1;

Thanks.
---

Re: [PATCH v2 4/4] ocfs2: check/fix inode block for online file check

[Junxiao Bi]

On 11/03/2015 04:47 PM, Gang He wrote:
> 
> 
> 

>> On 11/03/2015 04:15 PM, Gang He wrote:
>>> Hello Junxiao,
>>>
>>> See my comments inline.
>>>
>>>
>>
 Hi Gang,

 This is not like a right patch.
 First, online file check only checks inode's block number, valid flag,
 fs generation value, and meta ecc. I never see a real corruption
 happened only on this field, if these fields are corrupted, that means
 something bad may happen on other place. So fix this field may not help
 and even cause corruption more hard.
>>> This online file check/fix feature is used to check/fix some light file 
>>> meta 
>> block corruption, instead of turning a file system off and using fsck.ocfs2.
>> What's light meta block corruption? Do you have a case about it?
>>> e.g. meta ecc error, we really need not to use fsck.ocfs2. 
>>> of course, this feature does not replace fsck.ocfs2 and touch some 
>> complicated meta block problems, if there is some potential problem in some 
>> areas, we can discuss them one by one.
>>>
>>>
>>>
 Second, the repair way is wrong. In
 ocfs2_filecheck_repair_inode_block(), if these fields in disk don't
 match the ones in memory, the ones in memory are used to update the disk
 fields. The question is how do you know these field in memory are
 right(they may be the real corrupted ones)?
>>> Here, if the inode block was corrupted, the file system is not able to load 
>> it into the memory.
>> How do you know inode block corrupted? If bh for inode block is
>> overwritten, i mean bh corrupted, the repair will corrupted a good inode
>> block.
> You know, the meta block is only validated when the file system loads the 
> block from disk to memory.
> If the inode object is in the memory, we consider this inode block is OK.
This assuming is not true as there are always bugs. Bugs can make inode
object in memory bad and corrupted the fs when repair the inode.

Thanks,
Junxiao.
> If the inode is not loaded by the file system via the normal way, the file 
> system will print a kernel error log to tell which ino is corrupted.
> we will use  ocfs2_filecheck_repair_inode_block() function to fix the inode 
> block before loading.
> 
> Thanks
> Gang
> 
>>
>> Thanks,
>> Junxiao.
>>
>>> ocfs2_filecheck_repair_inode_block() will able to load it into the memory, 
>> since it try to fix these light-level problem before loading.
>>> if the fix is OK, the changed meta-block can pass the block-validate 
>>> function 
>> and load into the memory as a inode object.
>>> Since the file system is under a cluster environment, we have to use some 
>> existing function and code path to keep these block operation under a 
>> cluster 
>> lock.
>>>
>>>
>>> Thanks
>>> Gang
>>>

 Thanks,
 Junxiao.
 On 10/28/2015 02:26 PM, Gang He wrote:
> +static int ocfs2_filecheck_repair_inode_block(struct super_block *sb,
> +struct buffer_head *bh)
> +{
> + int rc;
> + int changed = 0;
> + struct ocfs2_dinode *di = (struct ocfs2_dinode *)bh->b_data;
> +
> + rc = ocfs2_filecheck_validate_inode_block(sb, bh);
> + /* Can't fix invalid inode block */
> + if (!rc || rc == -OCFS2_FILECHECK_ERR_INVALIDINO)
> + return rc;
> +
> + trace_ocfs2_filecheck_repair_inode_block(
> + (unsigned long long)bh->b_blocknr);
> +
> + if (ocfs2_is_hard_readonly(OCFS2_SB(sb)) ||
> + ocfs2_is_soft_readonly(OCFS2_SB(sb))) {
> + mlog(ML_ERROR,
> + "Filecheck: try to repair dinode #%llu on readonly 
> filesystem\n",
> + (unsigned long long)bh->b_blocknr);
> + return -OCFS2_FILECHECK_ERR_READONLY;
> + }
> +
> + if (le64_to_cpu(di->i_blkno) != bh->b_blocknr) {
> + di->i_blkno = cpu_to_le64(bh->b_blocknr);
> + changed = 1;
> + mlog(ML_ERROR,
> + "Filecheck: reset dinode #%llu: i_blkno to %llu\n",
> + (unsigned long long)bh->b_blocknr,
> + (unsigned long long)le64_to_cpu(di->i_blkno));
> + }
> +
> + if (!(di->i_flags & cpu_to_le32(OCFS2_VALID_FL))) {
> + di->i_flags |= cpu_to_le32(OCFS2_VALID_FL);
> + changed = 1;
> + mlog(ML_ERROR,
> + "Filecheck: reset dinode #%llu: OCFS2_VALID_FL is 
> set\n",
> + (unsigned long long)bh->b_blocknr);
> + }
> +
> + if (le32_to_cpu(di->i_fs_generation) !=
> + OCFS2_SB(sb)->fs_generation) {
> + di->i_fs_generation = cpu_to_le32(OCFS2_SB(sb)->fs_generation);
> + changed = 1;
> + mlog(ML_ERROR,
> + "Filecheck: reset dinode #%llu: fs_generation to %u\n",
> + (unsigned long long)bh->b_blocknr,
> + le32_to_cpu(di->i_fs_generation));
> + }
> +
> + if (changed ||
> + 

[GIT PULL] locking changes for v4.4

[Ingo Molnar]

Linus,

Please pull the latest locking-core-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
locking-core-for-linus

   # HEAD: 6e490b0106a2118ee4c37c37847454a5c2dc6e32 ARM, locking/atomics: 
Implement _relaxed variants of atomic[64]_{inc,dec}

The main changes in this cycle were:

  - More gradual enhancements to atomic ops: new atomic*_read_ctrl() ops, 
synchronize atomic_{read,set}() ordering requirements between 
architectures, 
add atomic_long_t bitops. (Peter Zijlstra)

  - Add _{relaxed|acquire|release}() variants for inc/dec atomics and use them 
in 
various locking primitives: mutex, rtmutex, mcs, rwsem. This enables weakly 
ordered architectures (such as arm64) to make use of more locking related
optimizations. (Davidlohr Bueso)

  - Implement atomic[64]_{inc,dec}_relaxed() on ARM. (Will Deacon)

  - Futex kernel data cache footprint micro-optimization. (Rasmus Villemoes)

  - pvqspinlock runtime overhead micro-optimization. (Waiman Long)

  - misc smaller fixlets.

 Thanks,

Ingo

-->
Boqun Feng (1):
  locking/atomics, cmpxchg: Privatize the inclusion of asm/cmpxchg.h

Davidlohr Bueso (7):
  locking/qrwlock: Rename ->lock to ->wait_lock
  locking/osq: Relax atomic semantics
  locking/asm-generic: Add _{relaxed|acquire|release}() variants for 
inc/dec atomics
  locking/mutex: Use acquire/release semantics
  locking/rtmutex: Use acquire/release semantics
  locking/mcs: Use acquire/release semantics
  locking/rwsem: Use acquire/release semantics

Peter Zijlstra (3):
  atomic: Add atomic_long_t bitops
  atomic, arch: Audit atomic_{read,set}()
  atomic: Implement atomic_read_ctrl()

Rasmus Villemoes (1):
  futex: Force hot variables into a single cache line

Stephen Boyd (1):
  locking/Documentation/lockstat: Fix typo - lokcing -> locking

Waiman Long (1):
  locking/pvqspinlock: Kick the PV CPU unconditionally when _Q_SLOW_VAL

Will Deacon (1):
  ARM, locking/atomics: Implement _relaxed variants of atomic[64]_{inc,dec}


 Documentation/atomic_ops.txt   |   4 ++
 Documentation/locking/lockstat.txt |   2 +-
 Documentation/memory-barriers.txt  |  17 ++---
 arch/alpha/include/asm/atomic.h|   8 +--
 arch/arc/include/asm/atomic.h  |   8 +--
 arch/arm/include/asm/atomic.h  |  12 ++--
 arch/arm64/include/asm/atomic.h|   2 +-
 arch/avr32/include/asm/atomic.h|   4 +-
 arch/frv/include/asm/atomic.h  |   4 +-
 arch/h8300/include/asm/atomic.h|   4 +-
 arch/hexagon/include/asm/atomic.h  |   2 +-
 arch/ia64/include/asm/atomic.h |   8 +--
 arch/m32r/include/asm/atomic.h |   4 +-
 arch/m68k/include/asm/atomic.h |   4 +-
 arch/metag/include/asm/atomic_lnkget.h |   2 +-
 arch/metag/include/asm/atomic_lock1.h  |   2 +-
 arch/mips/include/asm/atomic.h |   8 +--
 arch/mn10300/include/asm/atomic.h  |   4 +-
 arch/parisc/include/asm/atomic.h   |   2 +-
 arch/sh/include/asm/atomic.h   |   4 +-
 arch/sparc/include/asm/atomic_64.h |   8 +--
 arch/tile/include/asm/atomic.h |   2 +-
 arch/tile/include/asm/atomic_64.h  |   6 +-
 arch/x86/include/asm/atomic.h  |   4 +-
 arch/x86/include/asm/atomic64_64.h |   4 +-
 arch/xtensa/include/asm/atomic.h   |   4 +-
 drivers/net/ethernet/sfc/mcdi.c|   2 +-
 drivers/phy/phy-rcar-gen2.c|   3 +-
 drivers/staging/speakup/selection.c|   2 +-
 include/asm-generic/atomic-long.h  |  56 +---
 include/asm-generic/atomic.h   |   4 +-
 include/asm-generic/mutex-dec.h|   8 +--
 include/asm-generic/mutex-xchg.h   |  10 +--
 include/asm-generic/qrwlock_types.h|   4 +-
 include/asm-generic/rwsem.h|  21 --
 include/linux/atomic.h | 118 -
 kernel/futex.c |  13 +++-
 kernel/locking/mcs_spinlock.h  |   4 +-
 kernel/locking/mutex.c |   9 +--
 kernel/locking/osq_lock.c  |  11 ++-
 kernel/locking/qrwlock.c   |   8 +--
 kernel/locking/qspinlock_paravirt.h|   6 +-
 kernel/locking/rtmutex.c   |  30 ++---
 kernel/locking/rwsem-xadd.c|   5 +-
 44 files changed, 304 insertions(+), 143 deletions(-)

diff --git a/Documentation/atomic_ops.txt b/Documentation/atomic_ops.txt
index b19fc34efdb1..c9d1cacb4395 100644
--- a/Documentation/atomic_ops.txt
+++ b/Documentation/atomic_ops.txt
@@ -542,6 +542,10 @@ The routines xchg() and cmpxchg() must provide the same 
exact
 memory-barrier semantics as the atomic and bit operations returning
 values.
 
+Note: If someone wants to use xchg(), cmpxchg() and their variants,
+linux/atomic.h should be included rather than asm/cmpxchg.h, unless
+the code is in arch/* and can take care of itself.
+
 Spinlocks and rwlocks have memory barrier expectations as well.
 The r

Re: [PATCH v3 3/4] perf callchain: Add count fields to struct callchain_node

[Jiri Olsa]

On Tue, Nov 03, 2015 at 04:18:30PM +0900, Namhyung Kim wrote:
> It's to track the count of occurrences of the callchains.
> 
> Cc: Brendan Gregg 
> Signed-off-by: Namhyung Kim 

Acked-by: Jiri Olsa 

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

Re: [PATCH V3 2/3] perf/powerpc :add support for sampling intr machine state

[Michael Ellerman]

On Tue, 2015-11-03 at 11:40 +0530, Anju T wrote:

> The perf infrastructure uses a bit mask to find out
> valid registers to display. Define a register mask
> for supported registers defined in asm/perf_regs.h.
> The bit positions also correspond to register IDs
> which is used by perf infrastructure to fetch the register
> values.CONFIG_HAVE_PERF_REGS enables
> sampling of the interrupted machine state.

> diff --git a/arch/powerpc/perf/perf_regs.c b/arch/powerpc/perf/perf_regs.c
> new file mode 100644
> index 000..0520492
> --- /dev/null
> +++ b/arch/powerpc/perf/perf_regs.c
> @@ -0,0 +1,92 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define PT_REGS_OFFSET(id, r) [id] = offsetof(struct pt_regs, r)
> +
> +#define REG_RESERVED (~((1ULL << PERF_REG_POWERPC_MAX) - 1))
> +
> +static unsigned int pt_regs_offset[PERF_REG_POWERPC_MAX] = {
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR0, gpr[0]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR1, gpr[1]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR2, gpr[2]),



I realise you're following the example of other architectures, but we have
almost this exact same structure in ptrace.c, see regoffset_table.

It would be really nice if we could share them between ptrace and perf.

cheers

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v5 4/4] ARM: dts: Add Ethernet chip to SMDK5410

[Pavel Fedin]

The chip is smsc9115, connected via SROMc bank 3. Additionally, some GPIO
initialization is required.

Signed-off-by: Pavel Fedin 
---
 arch/arm/boot/dts/exynos5410-smdk5410.dts | 40 +++
 1 file changed, 40 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5410-smdk5410.dts 
b/arch/arm/boot/dts/exynos5410-smdk5410.dts
index cebeaab..f41952f 100644
--- a/arch/arm/boot/dts/exynos5410-smdk5410.dts
+++ b/arch/arm/boot/dts/exynos5410-smdk5410.dts
@@ -61,6 +61,27 @@
disable-wp;
 };
 
+&pinctrl_0 {
+   srom_ctl: srom-ctl {
+   samsung,pins = "gpy0-3", "gpy0-4", "gpy0-5",
+  "gpy1-0", "gpy1-1", "gpy1-2", "gpy1-3";
+   samsung,pin-function = <2>;
+   samsung,pin-drv = <0>;
+   };
+
+   srom_ebi: srom-ebi {
+   samsung,pins = "gpy3-0", "gpy3-1", "gpy3-2", "gpy3-3",
+  "gpy3-4", "gpy3-5", "gpy3-6", "gpy3-7",
+  "gpy5-0", "gpy5-1", "gpy5-2", "gpy5-3",
+  "gpy5-4", "gpy5-5", "gpy5-6", "gpy5-7",
+  "gpy6-0", "gpy6-1", "gpy6-2", "gpy6-3",
+  "gpy6-4", "gpy6-5", "gpy6-6", "gpy6-7";
+   samsung,pin-function = <2>;
+   samsung,pin-pud = <3>;
+   samsung,pin-drv = <0>;
+   };
+};
+
 &uart0 {
status = "okay";
 };
@@ -72,3 +93,22 @@
 &uart2 {
status = "okay";
 };
+
+&sromc {
+   pinctrl-names = "default";
+   pinctrl-0 = <&srom_ctl>, <&srom_ebi>;
+
+   ethernet@3 {
+   compatible = "smsc,lan9115";
+   reg = <3 0 0x1>;
+   phy-mode = "mii";
+   interrupt-parent = <&gpx0>;
+   interrupts = <5 8>;
+   reg-io-width = <2>;
+   smsc,irq-push-pull;
+   smsc,force-internal-phy;
+
+   samsung,srom-page-mode = <1>;
+   samsung,srom-timing = <9 12 1 9 1 1>;
+   };
+};
-- 
2.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/

[GIT PULL] EFI changes for v4.4

[Ingo Molnar]

Linus,

Please pull the latest core-efi-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core-efi-for-linus

   # HEAD: 78b9bc947b18ed16b6c2c573d774e6d54ad9452d efi: Fix warning of 
int-to-pointer-cast on x86 32-bit builds

The main changes in this cycle were:

 - further EFI code generalization to make it more workable for ARM64
 - various extensions, such as 64-bit framebuffer address support,
   UEFI v2.5 EFI_PROPERTIES_TABLE support 
 - code modularization simplifications and cleanups
 - new debugging parameters
 - various fixes and smaller additions

 Thanks,

Ingo

-->
Ard Biesheuvel (4):
  efi: Add support for EFI_MEMORY_RO attribute introduced by UEFIv2.5
  efi: Add support for UEFIv2.5 Properties table
  efi: Introduce EFI_NX_PE_DATA bit and set it from properties table
  efi: Use correct type for struct efi_memory_map::phys_map

Ben Hutchings (1):
  efi: Auto-load the efi-pstore module

Jonathan (Zhixiong) Zhang (5):
  efi, x86: Rearrange efi_mem_attributes()
  acpi, x86: Implement arch_apei_get_mem_attributes()
  arm64/mm: Add PROT_DEVICE_nGnRnE and PROT_NORMAL_WT
  arm64, acpi/apei: Implement arch_apei_get_mem_attributes()
  acpi/apei: Use appropriate pgprot_t to map GHES memory

Leif Lindholm (3):
  efi/x86: Move efi=debug option parsing to core
  arm64: Use core efi=debug instead of uefi_debug command line parameter
  efi/arm64: Clean up efi_get_fdt_params() interface

Matt Fleming (4):
  x86/efi-bgrt: Switch pr_err() to pr_debug() for invalid BGRT
  Revert "x86/efi: Request desired alignment via the PE/COFF headers"
  efi: Use the generic efi.memmap instead of 'memmap'
  efifb: Add support for 64-bit frame buffer addresses

Paul Gortmaker (1):
  drivers/firmware: Make efi/esrt.c driver explicitly non-modular

Sai Praneeth (1):
  x86/efi: Fix kernel panic when CONFIG_DEBUG_VIRTUAL is enabled

Taku Izumi (4):
  efi: Add EFI_MEMORY_MORE_RELIABLE support to efi_md_typeattr_format()
  x86/efi: Rename print_efi_memmap() to efi_print_memmap()
  efi: Add "efi_fake_mem" boot option
  efi: Fix warning of int-to-pointer-cast on x86 32-bit builds


 Documentation/arm/uefi.txt  |   2 -
 Documentation/kernel-parameters.txt |  15 +++
 arch/arm64/include/asm/acpi.h   |   5 +
 arch/arm64/include/asm/memory.h |   1 +
 arch/arm64/include/asm/pgtable.h|   2 +
 arch/arm64/kernel/acpi.c|  29 +
 arch/arm64/kernel/efi.c |  23 ++--
 arch/arm64/mm/proc.S|   4 +-
 arch/x86/boot/compressed/eboot.c|  28 -
 arch/x86/boot/header.S  |   2 +-
 arch/x86/include/asm/acpi.h |  23 
 arch/x86/include/asm/efi.h  |   1 +
 arch/x86/kernel/setup.c |   4 +-
 arch/x86/mm/pageattr.c  |   9 +-
 arch/x86/platform/efi/efi-bgrt.c|   9 +-
 arch/x86/platform/efi/efi.c |  28 +
 drivers/acpi/apei/ghes.c|  10 +-
 drivers/firmware/efi/Kconfig|  22 
 drivers/firmware/efi/Makefile   |   1 +
 drivers/firmware/efi/efi-pstore.c   |   1 +
 drivers/firmware/efi/efi.c  | 107 
 drivers/firmware/efi/esrt.c |  19 +--
 drivers/firmware/efi/fake_mem.c | 238 
 drivers/video/fbdev/efifb.c |  24 +++-
 include/linux/efi.h |  25 +++-
 include/uapi/linux/screen_info.h|   5 +-
 26 files changed, 532 insertions(+), 105 deletions(-)
 create mode 100644 drivers/firmware/efi/fake_mem.c

diff --git a/Documentation/arm/uefi.txt b/Documentation/arm/uefi.txt
index d60030a1b909..7b3fdfe0f7ba 100644
--- a/Documentation/arm/uefi.txt
+++ b/Documentation/arm/uefi.txt
@@ -60,5 +60,3 @@ linux,uefi-mmap-desc-ver  | 32-bit | Version of the mmap 
descriptor format.
 

 linux,uefi-stub-kern-ver  | string | Copy of linux_banner from build.
 

-
-For verbose debug messages, specify 'uefi_debug' on the kernel command line.
diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 22a4b687ea5b..50fc09b623f6 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1094,6 +1094,21 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
you are really sure that your UEFI does sane gc and
fulfills the spec otherwise your board may brick.
 
+   efi_fake_mem=   nn[KMG]@ss[KMG]:aa[,nn[KMG]@ss[KMG]:aa,..] [EFI; X86]
+   Add arbitrary attribute to specific memory range by
+   updating original EFI memory map.
+   Region of memory which aa attribute is added to is
+   from ss to ss+nn.
+   

Re: [PATCH v3 4/4] perf report: Add callchain value option

[Jiri Olsa]

On Tue, Nov 03, 2015 at 04:18:31PM +0900, Namhyung Kim wrote:
> Now -g/--call-graph option supports how to display callchain values.
> Possible values are 'percent', 'period' and 'count'.  The percent is
> same as before and it's the default behavior.  The period displays the
> raw period value rather than the percentage.  The count displays the
> number of occurrences.
> 
>   $ perf report --no-children --stdio -g percent
>   ...
> 39.93%  swapper  [kernel.vmlinux]  [k] intel_idel
> |
> ---intel_idle
>cpuidle_enter_state
>cpuidle_enter
>call_cpuidle
>cpu_startup_entry
>|
>|--28.63%-- start_secondary
>|
> --11.30%-- rest_init
> 
>   $ perf report --no-children --show-total-period --stdio -g period
>   ...
> 39.93%   13018705  swapper  [kernel.vmlinux]  [k] intel_idel
> |
> ---intel_idle
>cpuidle_enter_state
>cpuidle_enter
>call_cpuidle
>cpu_startup_entry
>|
>|--9334403-- start_secondary
>|
> --3684302-- rest_init
> 
>   $ perf report --no-children --show-nr-samples --stdio -g count
>   ...
> 39.93% 80  swapper  [kernel.vmlinux]  [k] intel_idel
> |
> ---intel_idle
>cpuidle_enter_state
>cpuidle_enter
>call_cpuidle
>cpu_startup_entry
>|
>|--57-- start_secondary
>|
> --23-- rest_init
> 
> Cc: Brendan Gregg 
> Signed-off-by: Namhyung Kim 
> ---
>  tools/perf/Documentation/perf-report.txt | 13 ---
>  tools/perf/builtin-report.c  |  4 +--
>  tools/perf/ui/stdio/hist.c   | 10 +-
>  tools/perf/util/callchain.c  | 60 
> +++-
>  tools/perf/util/callchain.h  | 10 +-
>  tools/perf/util/util.c   |  3 +-
>  6 files changed, 83 insertions(+), 17 deletions(-)
> 
> diff --git a/tools/perf/Documentation/perf-report.txt 
> b/tools/perf/Documentation/perf-report.txt
> index 5ce8da1e1256..bb9fd23a105e 100644
> --- a/tools/perf/Documentation/perf-report.txt
> +++ b/tools/perf/Documentation/perf-report.txt
> @@ -170,11 +170,11 @@ OPTIONS
>  Dump raw trace in ASCII.
>  
>  -g::
> ---call-graph=::
> +--call-graph=::
>  Display call chains using type, min percent threshold, print limit,
> - call order, sort key and branch.  Note that ordering of parameters is 
> not
> - fixed so any parement can be given in an arbitraty order.  One exception
> - is the print_limit which should be preceded by threshold.
> + call order, sort key, optional branch and value.  Note that ordering of
> + parameters is not fixed so any parement can be given in an arbitraty 
> order.
> + One exception is the print_limit which should be preceded by threshold.
>  
>   print_type can be either:
>   - flat: single column, linear exposure of call chains.
> @@ -204,6 +204,11 @@ OPTIONS
>   - branch: include last branch information in callgraph when available.
> Usually more convenient to use --branch-history for this.
>  
> + value can be:
> + - percent: diplay overhead percent (default)
> + - period: display event period
> + - count: display evnt count

s/evnt/event/

jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v5 0/4] Exynos SROMc configuration and Ethernet support for SMDK5410

[Pavel Fedin]

This patch extends Exynos SROM controller driver with ability to configure
controller outputs and enables SMSC9115 Ethernet chip on SMDK5410 board,
which is connected via SROMc bank #3.

With this patchset, support for the whole existing SMDK range can be added.
Actually, only bank number is different.

This patchset also depends on Exynos 5410 pinctrl support, introduced by
patches 0003 and 0004 from this set:
[PATCH v4 0/5] ARM: EXYNOS: ODROID-XU DT and LEDs
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-March/330862.html

Pinctrl support is necessary in order to correctly configure
multifunctional pins of the Exynos chip.

v4 => v5:
- Some cosmetic changes in the dtsi ("compatible" goes first)
- Use correctly specified ranges for the SROMc node
- Reuse existing properties where possible ("reg" for bank# and
  "reg-io-width" for data width)
- Separated page-mode property from timings array
- More improvements to the documentation

v3 => v4:
- Devices are now added as subnodes, with additional properties. This allows
  to cleary specify dependency. If configuration fails, error will be reported
  and child devices will not be probed.
- These additional properties now have "samsung,srom-XXX" format
- Fixed code style, now better understood.

v2 => v3:
- Fixed up SROMc region size in the device tree
- Reordered patches, documentation goes first now

v1 => v2:
- Fixed some typos and bad labels in device tree
- Improved documentation

Pavel Fedin (4):
  Documentation: dt-bindings: Describe SROMc configuration
  ARM: dts: Add SROMc to Exynos 5410
  drivers: exynos-srom: Add support for bank configuration
  ARM: dts: Add Ethernet chip to SMDK5410

 .../bindings/arm/samsung/exynos-srom.txt   | 68 +-
 arch/arm/boot/dts/exynos5410-smdk5410.dts  | 40 +
 arch/arm/boot/dts/exynos5410.dtsi  | 11 
 arch/arm/mach-exynos/Kconfig   |  2 +-
 drivers/soc/samsung/Kconfig|  2 +-
 drivers/soc/samsung/exynos-srom.c  | 60 ++-
 6 files changed, 177 insertions(+), 6 deletions(-)

-- 
2.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: [RESEND PATCH] ARM: errata: Workaround for Cortex-A12 erratum 818325

[Caesar Wang]

在 2015年11月03日 16:45, Arnd Bergmann 写道:

On Tuesday 03 November 2015 16:10:09 Caesar Wang wrote:

+   /* Cortex-A12 Errata */
+   ldr r10, =0x0c0d@ Cortex-A12 primary part number
+   teq r0, r10
+   bne 5f


beq  __ca15_errata:

+#ifdef CONFIG_ARM_ERRATA_818325
+   teq r6, #0x00   @ present in r0p0
+   teqne   r6, #0x01   @ present in r0p1-00lac0-rc11
+   mrceq   p15, 0, r10, c15, c0, 1 @ read diagnostic register
+   orreq   r10, r10, #1 << 12  @ set bit #12
+   mcreq   p15, 0, r10, c15, c0, 1 @ write diagnostic register
+   isb
+#endif
 /* Cortex-A15 Errata */


Does this still build? You seem to have lost the '5:' label.


No,  I didn't have build in next kernel.

Yup,  the patch need a bit change from the message.

commit 17e7bf86690eaad4906d2295f0bd171cc194633b
Author: Russell King 
Date:   Sat Apr 4 21:34:33 2015 +0100

ARM: proc-v7: move CPU errata out of line



-
Original patch:
https://patchwork.kernel.org/patch/4735341/

Applied and verified on kernel V3.14.





Arnd

___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel



--
Thanks,
Caesar

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

RE: [PATCH 0/3] Fix rcar-pcie for arm64

[Phil Edworthy]

Hi Wolfram,

On 02 November 2015 21:33, Wolfram wrote:
> > The first patches fixes the build problem, and the second patch reverts the
> > patch that removed the driver from arm64 builds. The final patch add a 
> > compat
> > string for the r8a7795 (arm64) device.
> 
> Thanks. I will test them next week when I have access to my board again.
It's worth mentioning that I had some troubles on my Salvator-X board
with some cards not being able to link up. Since my board has a socketed chip
and the board was designed for it not to be via a socket, and this is such a low
level functionality, I think this is HW related. My Intel Gigabit CT Desktop 
card
always works.
Also note that this PCIe controller only supports a 32-bit AXI address range,
so you need to limit memory to within the 4GiB address space. As far as I am
aware, there is no way to limit the dma mask that card drivers use via the
controller. The plan is to add support this via IOMMU.
 
> > Apart from patches to add the PCIe clock and DT nodes, I had to revert these
> > patches to get it to work on arm64:
> >  f075915ac0b1 ("PCI/MSI: Drop domain field from msi_controller")
> >  d8a1cb757550 ("PCI/MSI: Let pci_msi_get_domain use struct
> device::msi_domain")
> 
> Does that solve the MSI problems you mentioned?
It avoids the problem, but I have a proper fix in the pipeline which just needs
more testing.

Thanks
Phil

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/5] do_div(): generic optimization for constant divisor on 32-bit machines

[Arnd Bergmann]

On Tuesday 03 November 2015 13:32:17 kbuild test robot wrote:
> 
>net/can/bcm.c: In function 'bcm_proc_show':
> >> net/can/bcm.c:223:1: warning: the frame size of 1156 bytes is larger than 
> >> 1024 bytes [-Wframe-larger-than=]
> }

Interesting, that is a lot of stack for a function that only has a couple
of local variables:

#define IFNAMSIZ16
char ifname[IFNAMSIZ];
struct sock *sk = (struct sock *)m->private;
struct bcm_sock *bo = bcm_sk(sk);
struct bcm_op *op;


This is a parisc-allyesconfig kernel, so I assume that 
CONFIG_PROFILE_ALL_BRANCHES
is on, which instruments every 'if' in the kernel. If that causes problems,
we could decide to disable the do_div optimization whenever 
CONFIG_PROFILE_ALL_BRANCHES
is enabled.

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

Re: [PATCH RESEND 00/16] Support TI LMU devices

[Kim, Milo]

On 11/3/2015 5:33 PM, Lee Jones wrote:

On Tue, 03 Nov 2015, Kim, Milo wrote:


Hi Lee,

On 11/2/2015 5:59 PM, Lee Jones wrote:

  drivers/video/backlight/Kconfig|  62 ++

  drivers/video/backlight/Makefile   |   7 +
  drivers/video/backlight/lm3532_bl.c| 183 +
  drivers/video/backlight/lm3631_bl.c| 129 
  drivers/video/backlight/lm3632_bl.c| 125 
  drivers/video/backlight/lm3633_bl.c| 210 ++
  drivers/video/backlight/lm3695_bl.c|  91 +++
  drivers/video/backlight/lm3697_bl.c| 187 +
  drivers/video/backlight/ti-lmu-backlight.c | 429 
  drivers/video/backlight/ti-lmu-backlight.h | 152 +

How different are all of these drivers?

Can you create one driver that supports them all instead?



Thanks for your suggestion.

'ti-lmu-backlight' is the common part of lm_bl drivers. And each
lmxxx_bl has its own operation functions by using ti_lmu_bl_ops.
I've tried to make consolidated driver but it contained too much
device specific code in one file. So I prefer simple drivers
structure - 'common part' and 'device specific operations'.
It would be appreciated if you could introduce better idea.


I wish to avoid having to apply the patches to conduct my own analysis
of the files, as I am severely restricted on time.  Can you tell me how
much duplicated code there is between the files?  How many lines would
be saved by supporting all of the lm* drivers in a single file?



Understood. Let me try it again. I'll get back to you soon.
Thanks for your help.

Best regards,
Milo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 BUGFIX 2/3] null_blk: guarantee device restart in all irq modes

[Paolo Valente]

Il giorno 02/nov/2015, alle ore 17:25, Jens Axboe  ha scritto:

> On 11/02/2015 07:31 AM, Paolo Valente wrote:
>> From: Arianna Avanzini 
>> 
>> In single-queue (block layer) mode,the function null_rq_prep_fn stops
>> the device if alloc_cmd fails. Then, once stopped, the device must be
>> restarted on the next command completion, so that the request(s) for
>> which alloc_cmd failed can be requeued. Otherwise the device hangs.
>> 
>> Unfortunately, device restart is currently performed only for delayed
>> completions, i.e., in irqmode==2. This fact causes hangs, for the
>> above reasons, with the other irqmodes in combination with single-queue
>> block layer.
>> 
>> This commits addresses this issue by making sure that, if stopped, the
>> device is properly restarted for all irqmodes on completions.
> 
> This looks good. I did a double take at the removal of the q->mq_ops check 
> before blk_queue_stopped(), but we can't get there in MQ mode. Perhaps a 
> comment would be warranted for that, the ->mq_ops check served as a bit of 
> documentation for that before.
> 

Honestly, I removed that additional check by mistake. I will put it back in the 
next version of this patchset, once (and if) I have the green light on patch 
1/3.

Thanks,
Paolo

> -- 
> Jens Axboe
> 


--
Paolo Valente 
Algogroup
Dipartimento di Fisica, Informatica e Matematica
Via Campi, 213/B
41125 Modena - Italy  
homepage:  http://algogroup.unimore.it/people/paolo/

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

[RFC PATCH] x86/paravirt: Kill some unused patching functions

[Borislav Petkov]

From: Borislav Petkov 

paravirt_patch_ignore() is completely unused and paravirt_patch_nop()
doesn't do a whole lot. Remove them both.

Signed-off-by: Borislav Petkov 
Cc: Andrew Morton 
Cc: Andy Lutomirski 
Cc: Chris Wright 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Jeremy Fitzhardinge 
Cc: Juergen Gross 
Cc: "Peter Zijlstra (Intel)" 
Cc: Rusty Russell 
Cc: Thomas Gleixner 
Cc: virtualizat...@lists.linux-foundation.org
Cc: xen-de...@lists.xenproject.org
---
 arch/x86/include/asm/paravirt_types.h |  2 --
 arch/x86/kernel/paravirt.c| 13 +
 2 files changed, 1 insertion(+), 14 deletions(-)

diff --git a/arch/x86/include/asm/paravirt_types.h 
b/arch/x86/include/asm/paravirt_types.h
index 31247b5bff7c..e1f31dfc3b31 100644
--- a/arch/x86/include/asm/paravirt_types.h
+++ b/arch/x86/include/asm/paravirt_types.h
@@ -402,10 +402,8 @@ extern struct pv_lock_ops pv_lock_ops;
__visible extern const char start_##ops##_##name[], 
end_##ops##_##name[];   \
asm(NATIVE_LABEL("start_", ops, name) code NATIVE_LABEL("end_", ops, 
name))
 
-unsigned paravirt_patch_nop(void);
 unsigned paravirt_patch_ident_32(void *insnbuf, unsigned len);
 unsigned paravirt_patch_ident_64(void *insnbuf, unsigned len);
-unsigned paravirt_patch_ignore(unsigned len);
 unsigned paravirt_patch_call(void *insnbuf,
 const void *target, u16 tgt_clobbers,
 unsigned long addr, u16 site_clobbers,
diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
index c2130aef3f9d..4f32a10979db 100644
--- a/arch/x86/kernel/paravirt.c
+++ b/arch/x86/kernel/paravirt.c
@@ -74,16 +74,6 @@ void __init default_banner(void)
 /* Undefined instruction for dealing with missing ops pointers. */
 static const unsigned char ud2a[] = { 0x0f, 0x0b };
 
-unsigned paravirt_patch_nop(void)
-{
-   return 0;
-}
-
-unsigned paravirt_patch_ignore(unsigned len)
-{
-   return len;
-}
-
 struct branch {
unsigned char opcode;
u32 delta;
@@ -152,8 +142,7 @@ unsigned paravirt_patch_default(u8 type, u16 clobbers, void 
*insnbuf,
/* If there's no function, patch it with a ud2a (BUG) */
ret = paravirt_patch_insns(insnbuf, len, ud2a, 
ud2a+sizeof(ud2a));
else if (opfunc == _paravirt_nop)
-   /* If the operation is a nop, then nop the callsite */
-   ret = paravirt_patch_nop();
+   ret = 0;
 
/* identity functions just return their single argument */
else if (opfunc == _paravirt_ident_32)
-- 
2.3.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/

[GIT PULL] RCU changes for v4.4

[Ingo Molnar]

Linus,

Please pull the latest core-rcu-for-linus git tree from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core-rcu-for-linus

   # HEAD: b33e18f61bd18227a456016a77b1a968f5bc1d65 fs/writeback, rcu: Don't 
use list_entry_rcu() for pointer offsetting in bdi_split_work_to_wbs()

The main changes in this cycle were:

  - Improvements to expedited grace periods. (Paul E. McKenney)

  - Performance improvements to and locktorture tests for percpu-rwsem.
(Oleg Nesterov, Paul E. McKenney)

  - Torture-test changes. (Paul E. McKenney, Davidlohr Bueso)

  - Documentation updates. (Paul E. McKenney)

  - Miscellaneous fixes. (Paul E. McKenney, Boqun Feng, Oleg Nesterov, Patrick 
Marlier)

 Thanks,

Ingo

-->
Boqun Feng (3):
  rcu: Use rcu_callback_t in call_rcu*() and friends
  rcu: Use call_rcu_func_t to replace explicit type equivalents
  rcu: Don't disable preemption for Tiny and Tree RCU readers

Davidlohr Bueso (2):
  sched: Export sched_setscheduler_nocheck
  locktorture: Support rtmutex torturing

Jason A. Donenfeld (1):
  documentation: Correct doc to use rcu_dereference_protected

Oleg Nesterov (9):
  rcu: Create rcu_sync infrastructure
  rcu_sync: Simplify rcu_sync using new rcu_sync_ops structure
  rcu_sync: Add CONFIG_PROVE_RCU checks
  rcu_sync: Introduce rcu_sync_dtor()
  locking/percpu-rwsem: Make percpu_free_rwsem() after kzalloc() safe
  locking/percpu-rwsem: Make use of the rcu_sync infrastructure
  locking/percpu-rwsem: Fix the comments outdated by rcu_sync
  locking/percpu-rwsem: Clean up the lockdep annotations in 
percpu_down_read()
  rcu_sync: Cleanup the CONFIG_PROVE_RCU checks

Patrick Marlier (1):
  rculist: Make list_entry_rcu() use lockless_dereference()

Paul E. McKenney (36):
  rcu: Use rsp->expedited_wq instead of sync_rcu_preempt_exp_wq
  rcu: Move rcu_report_exp_rnp() to allow consolidation
  rcu: Consolidate tree setup for synchronize_rcu_expedited()
  rcu: Use single-stage IPI algorithm for RCU expedited grace period
  rcu: Move synchronize_sched_expedited() to combining tree
  rcu: Rename qs_pending to core_needs_qs
  rcu: Invert passed_quiesce and rename to cpu_no_qs
  rcu: Make ->cpu_no_qs be a union for aggregate OR
  rcu: Eliminate panic when silly boot-time fanout specified
  rcu: Add online/offline info to stall warning message
  rcu: Move preemption disabling out of __srcu_read_lock()
  rcu: Correct comment for values of ->gp_state field
  rcu: Add rcu_pointer_handoff()
  rcu: Remove deprecated rcu_lockdep_assert()
  rculist: Use WRITE_ONCE() when deleting from reader-visible list
  documentation: No acquire/release for RCU readers
  documentation: Call out slow consoles as cause of stall warnings
  documentation: Catch up list of torture_type options
  documentation: Add lockless_dereference()
  locking/percpu-rwsem: Export symbols for locktorture
  locktorture: Add torture tests for percpu_rwsem
  torture: Consolidate cond_resched_rcu_qs() into stutter_wait()
  rcutorture: Fix module unwind when bad torture_type specified
  rcutorture: Fix unused-function warning for torturing_tasks()
  torture: Forgive non-plural arguments
  locktorture: Fix module unwind when bad torture_type specified
  rcu: Switch synchronize_sched_expedited() to IPI
  rcu: Stop silencing lockdep false positive for expedited grace periods
  rcu: Stop excluding CPU hotplug in synchronize_sched_expedited()
  cpu: Remove try_get_online_cpus()
  rcu: Prepare for consolidating expedited CPU selection
  rcu: Consolidate expedited CPU selection
  rcu: Add online/offline info to expedited stall warning message
  rcu: Add tasks to expedited stall-warning messages
  rcu: Enable stall warnings for synchronize_rcu_expedited()
  rcu: Better hotplug handling for synchronize_sched_expedited()

Petr Mladek (1):
  rcu: Finish folding ->fqs_state into ->gp_state

Tejun Heo (1):
  fs/writeback, rcu: Don't use list_entry_rcu() for pointer offsetting in 
bdi_split_work_to_wbs()


 Documentation/RCU/stallwarn.txt|   7 +
 Documentation/RCU/torture.txt  |  39 +-
 Documentation/RCU/trace.txt|  32 +-
 Documentation/RCU/whatisRCU.txt|   6 +-
 Documentation/kernel-parameters.txt|   9 +-
 Documentation/locking/locktorture.txt  |   3 +
 Documentation/memory-barriers.txt  |  12 +-
 fs/fs-writeback.c  |   4 +-
 include/linux/cpu.h|   2 -
 include/linux/list.h   |   5 +-
 include/linux/list_bl.h|   5 +-
 include/linux/list_nulls.h |   3 +-
 include/linux/percpu-rwsem.h   | 

Re: [GIT PULL]: CRIS changes for 4.4

[Jesper Nilsson]

On Tue, Nov 03, 2015 at 01:49:23AM +0100, Stephen Rothwell wrote:
> Hi Jesper,
> 
> On Mon, 2 Nov 2015 21:17:03 +0100 Jesper Nilsson  
> wrote:
> >
> > Please pull CRIS changes for 4.4:
> > 
> > Mostly another batch of code removal due to move to standard
> > frameworks for CRISv32, initial devicetree configuration for
> > a couple of boards, and some small fixes for kgdb and time handling.
> > 
> > Thanks,
> > 
> > /Jesper
> > 
> > The following changes since commit 6a13feb9c82803e2b815eca72fa7a9f5561d7861:
> > 
> >   Linux 4.3 (2015-11-01 16:05:25 -0800)
> > 
> > are available in the git repository at:
> > 
> >   git://git.kernel.org/pub/scm/linux/kernel/git/jesper/cris.git 
> > tags/cris-for-4.4
> 
> This is all the same patches as are in linux-next (and have been for
> some time) but has been rebased on top of v4.3 today ...

Yes, you're right, I did do a rebase to make a final
compile test, I should have dropped that branch and
sent the for-next branch instead. :-(

> Cheers,
> Stephen Rothwells...@canb.auug.org.au

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

[PATCH v5 3/4] drivers: exynos-srom: Add support for bank configuration

[Pavel Fedin]

Implement handling properties in subnodes and adding child devices to the
system. Child devices will not be added if configuration fails.

Since the driver now does more than suspend-resume support, dependency on
CONFIG_PM is removed.

Signed-off-by: Pavel Fedin 
---
 arch/arm/mach-exynos/Kconfig  |  2 +-
 drivers/soc/samsung/Kconfig   |  2 +-
 drivers/soc/samsung/exynos-srom.c | 60 +--
 3 files changed, 60 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig
index 83c85f5..c22dc42 100644
--- a/arch/arm/mach-exynos/Kconfig
+++ b/arch/arm/mach-exynos/Kconfig
@@ -16,7 +16,7 @@ menuconfig ARCH_EXYNOS
select ARM_GIC
select COMMON_CLK_SAMSUNG
select EXYNOS_THERMAL
-   select EXYNOS_SROM if PM
+   select EXYNOS_SROM
select HAVE_ARM_SCU if SMP
select HAVE_S3C2410_I2C if I2C
select HAVE_S3C2410_WATCHDOG if WATCHDOG
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
index 2833b5b..ea4bc2a 100644
--- a/drivers/soc/samsung/Kconfig
+++ b/drivers/soc/samsung/Kconfig
@@ -8,6 +8,6 @@ config SOC_SAMSUNG
 
 config EXYNOS_SROM
bool
-   depends on ARM && ARCH_EXYNOS && PM
+   depends on ARM && ARCH_EXYNOS
 
 endmenu
diff --git a/drivers/soc/samsung/exynos-srom.c 
b/drivers/soc/samsung/exynos-srom.c
index 57a232d..49b5c9e 100644
--- a/drivers/soc/samsung/exynos-srom.c
+++ b/drivers/soc/samsung/exynos-srom.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -67,11 +68,50 @@ static struct exynos_srom_reg_dump 
*exynos_srom_alloc_reg_dump(
return rd;
 }
 
+static int decode_sromc(struct exynos_srom *srom, struct device_node *np)
+{
+   u32 bank, width, pmc;
+   u32 timing[6];
+   u32 cs, bw;
+
+   if (of_property_read_u32(np, "reg", &bank))
+   return -EINVAL;
+   if (of_property_read_u32(np, "reg-io-width", &width))
+   width = 1;
+   if (of_property_read_u32(np, "samsung,srom-page-mode", &pmc))
+   pmc = 0;
+   if (of_property_read_u32_array(np, "samsung,srom-timing", timing,
+  ARRAY_SIZE(timing)))
+   return -EINVAL;
+
+   bank *= 4; /* Convert bank into shift/offset */
+
+   cs = 1 << EXYNOS_SROM_BW__BYTEENABLE__SHIFT;
+   if (width == 2)
+   cs |= 1 << EXYNOS_SROM_BW__DATAWIDTH__SHIFT;
+
+   bw = __raw_readl(srom->reg_base + EXYNOS_SROM_BW);
+   bw = (bw & ~(EXYNOS_SROM_BW__CS_MASK << bank)) | (cs << bank);
+   __raw_writel(bw, srom->reg_base + EXYNOS_SROM_BW);
+
+   __raw_writel((pmc << EXYNOS_SROM_BCX__PMC__SHIFT) |
+   (timing[0] << EXYNOS_SROM_BCX__TACP__SHIFT) |
+   (timing[1] << EXYNOS_SROM_BCX__TCAH__SHIFT) |
+   (timing[2] << EXYNOS_SROM_BCX__TCOH__SHIFT) |
+   (timing[3] << EXYNOS_SROM_BCX__TACC__SHIFT) |
+   (timing[4] << EXYNOS_SROM_BCX__TCOS__SHIFT) |
+   (timing[5] << EXYNOS_SROM_BCX__TACS__SHIFT),
+   srom->reg_base + EXYNOS_SROM_BC0 + bank);
+
+   return 0;
+}
+
 static int exynos_srom_probe(struct platform_device *pdev)
 {
-   struct device_node *np;
+   struct device_node *np, *child;
struct exynos_srom *srom;
struct device *dev = &pdev->dev;
+   bool error = false;
 
np = dev->of_node;
if (!np) {
@@ -100,7 +140,23 @@ static int exynos_srom_probe(struct platform_device *pdev)
return -ENOMEM;
}
 
-   return 0;
+   for_each_child_of_node(np, child) {
+   if (decode_sromc(srom, child)) {
+   dev_err(dev,
+   "Could not decode bank configuration for %s\n",
+   child->name);
+   error = true;
+   }
+   }
+
+   /*
+* If any bank failed to configure, we still provide suspend/resume,
+* but do not probe child devices
+*/
+   if (error)
+   return 0;
+
+   return of_platform_populate(np, NULL, NULL, dev);
 }
 
 static int exynos_srom_remove(struct platform_device *pdev)
-- 
2.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 BUGFIX 1/3] null_blk: set a separate timer for each command

[Paolo Valente]

Il giorno 02/nov/2015, alle ore 17:14, Jens Axboe  ha scritto:

> On 11/02/2015 07:31 AM, Paolo Valente wrote:
>> For the Timer IRQ mode (i.e., when command completions are delayed),
>> there is one timer for each CPU. Each of these timers
>> . has a completion queue associated with it, containing all the
>>   command completions to be executed when the timer fires;
>> . is set, and a new completion-to-execute is inserted into its
>>   completion queue, every time the dispatch code for a new command
>>   happens to be executed on the CPU related to the timer.
>> 
>> This implies that, if the dispatch of a new command happens to be
>> executed on a CPU whose timer has already been set, but has not yet
>> fired, then the timer is set again, to the completion time of the
>> newly arrived command. When the timer eventually fires, all its queued
>> completions are executed.
>> 
>> This way of handling delayed command completions entails the following
>> problem: if more than one command completion is inserted into the
>> queue of a timer before the timer fires, then the expiration time for
>> the timer is moved forward every time each of these completions is
>> enqueued. As a consequence, only the last completion enqueued enjoys a
>> correct execution time, while all previous completions are unjustly
>> delayed until the last completion is executed (and at that time they
>> are executed all together).
>> 
>> Specifically, if all the above completions are enqueued almost at the
>> same time, then the problem is negligible. On the opposite end, if
>> every completion is enqueued a while after the previous completion was
>> enqueued (in the extreme case, it is enqueued only right before the
>> timer would have expired), then every enqueued completion, except for
>> the last one, experiences an inflated delay, proportional to the number
>> of completions enqueued after it. In the end, commands, and thus I/O
>> requests, may be completed at an arbitrarily lower rate than the
>> desired one.
>> 
>> This commit addresses this issue by replacing per-CPU timers with
>> per-command timers, i.e., by associating an individual timer with each
>> command.
> 
> Functionally the patch looks fine. My only worry is that a timer per command 
> would be an unnecessary slowdown compared to pushing one timer forward. The 
> problem should be fixable by still doing that, just maintaining next-expire 
> instead. Maybe something that would still roughly be precise enough, while 
> still getting some completion batching going? Or maybe that would be slower, 
> and the individual timers are still better.
> 
> Comments?
> 

I have tried to think about these questions. Unfortunately I was not able to go 
beyond the following general considerations.

Given that:
1) hrtimer_start is very efficient;
2) to implement a batch-by-batch execution of command completions, a more 
complex code would of course be needed in null_blk;
I think that, to get a perceptible improvement, command completions should 
probably be executed in batches of at least 3 or 4 commands each.

In this respect, commands can accumulate in a batch only if the time 
granularity with which delayed commands are guaranteed to be executed, i.e, the 
granularity with which timers eventually fire, happens to be coarser than 
completion_nsec. But this would lead to the exact uncontrolled throughput-loss 
problem addressed by this patch, although at a lesser extent. The reason is as 
follows.

Consider a batch of 3 or 4 commands, executed at a certain timer expiration. If 
the arrival time of these commands is close to the timer expiration, then the 
commands happen to be executed with a delay close to the expected one. If, on 
the other hand, their arrival time is far from the timer expiration, then they 
are completed with a larger delay. In the worst case, their delay is inflated 
by a factor proportional to the size of the batch, namely 3 or 4.

In the end, depending on the command arrival pattern, the throughput of the 
emulated device may vary by 3 or 4 times. This would be a reduced version of 
the issue addressed by this patch. In fact, with the current implementation of 
delayed completions (per-cpu timers), the throughput may vary, in the worst 
case, by a factor equal to the queue depth (64 by default).

Finally, a side note: as for whether the increased efficiency of batched 
delayed completions is worth additional code complexity as well as throughput 
losses/fluctuations, the low delays for which this efficiency becomes important 
match the latencies of new very fast devices (or are at least in the same 
order). But, exactly for the high speed of these devices, what typically 
matters (AFAIK) in tests with these devices is understanding whether the rest 
of the system can cope with their speed. And for this type of measures, the 
best/typical choice is (again, AFAIK) not to delay request completions at all 
in null_blk.

I hope these considerations may be somehow usefu

Re: [PATCH v3 4/4] perf report: Add callchain value option

[Jiri Olsa]

On Tue, Nov 03, 2015 at 04:18:31PM +0900, Namhyung Kim wrote:

SNIP

> @@ -819,12 +837,26 @@ char *callchain_node__sprintf_value(struct 
> callchain_node *node,
>   char *bf, size_t bfsize, u64 total)
>  {
>   double percent = 0.0;
> - u64 cumul = callchain_cumul_hits(node);
> + u64 period = callchain_cumul_hits(node);
> + int count = callchain_cumul_counts(node);
>  
>   if (total)
> - percent = cumul * 100.0 / total;
> + percent = period * 100.0 / total;
> + if (callchain_param.mode == CHAIN_FOLDED)
> + count = node->count;

this could be set/computed below in respective cases

>  
> - scnprintf(bf, bfsize, "%6.2f%%", percent);
> + switch (callchain_param.value) {
> + case CCVAL_PERIOD:
> + scnprintf(bf, bfsize, "%"PRIu64, period);
> + break;
> + case CCVAL_COUNT:
> + scnprintf(bf, bfsize, "%u", count);
> + break;
> + case CCVAL_PERCENT:
> + default:
> + scnprintf(bf, bfsize, "%.2f%%", percent);
> + break;
> + }
>   return bf;
>  }
>  
> @@ -832,12 +864,24 @@ int callchain_node__fprintf_value(struct callchain_node 
> *node,
>FILE *fp, u64 total)
>  {
>   double percent = 0.0;
> - u64 cumul = callchain_cumul_hits(node);
> + u64 period = callchain_cumul_hits(node);
> + int count = callchain_cumul_counts(node);
>  
>   if (total)
> - percent = cumul * 100.0 / total;
> -
> - return percent_color_fprintf(fp, "%.2f%%", percent);
> + percent = period * 100.0 / total;
> + if (callchain_param.mode == CHAIN_FOLDED)
> + count = node->count;
> +

ditto

jirka

> + switch (callchain_param.value) {
> + case CCVAL_PERIOD:
> + return fprintf(fp, "%"PRIu64, period);
> + case CCVAL_COUNT:
> + return fprintf(fp, "%u", count);
> + case CCVAL_PERCENT:
> + default:
> + return percent_color_fprintf(fp, "%.2f%%", percent);
> + }
> + return 0;
>  }
>  

SNIP
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v5 1/4] Documentation: dt-bindings: Describe SROMc configuration

[Pavel Fedin]

Add documentation for new subnode properties, allowing bank configuration.
Based on u-boot implementation, but heavily reworked.

Signed-off-by: Pavel Fedin 
---
 .../bindings/arm/samsung/exynos-srom.txt   | 68 +-
 1 file changed, 66 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt 
b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
index 33886d5..ee378ca 100644
--- a/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
+++ b/Documentation/devicetree/bindings/arm/samsung/exynos-srom.txt
@@ -5,8 +5,72 @@ Required properties:
 
 - reg: offset and length of the register set
 
-Example:
+- #address-cells: Must be set to 2 to allow memory address translation
+
+- #size-cells: Must be set to 1 to allow CS address passing
+
+- ranges: Must be set up to reflect the memory layout with four integer values
+ per bank:
+0  
+
+Sub-nodes:
+The SROM controller can be used to attach external peripherials. In this case
+device nodes should be added as subnodes to the SROMc node. These subnodes,
+except regular device specification, should contain the following properties,
+describing configuration of the relevant SROM bank:
+
+Required properties:
+- reg: bank number, base address (relative to start of the bank) and size of
+   the memory mapped for the device. Note that base address will be
+   typically 0 as this is the start of the bank.
+
+- samsung,srom-timing : array of 6 integers, specifying bank timings in the
+following order: Tacp, Tcah, Tcoh, Tacc, Tcos, Tacs.
+Each value is specified in cycles (0 - 15) and has the
+following meaning:
+Tacp : Page mode access cycle at Page mode
+Tcah : Address holding time after CSn
+Tcoh : Chip selection hold on OEn
+Tacc : Access cycle
+Tcos : Chip selection set-up before OEn
+Tacs : Address set-up before CSn
+
+Optional properties:
+- reg-io-width : data width in bytes (1 or 2). If omitted, default of 1 is 
used.
+
+- samsung,srom-page-mode : page mode configuration for the bank:
+  0 - normal (one data)
+  1 - four data
+  If omitted, default of 0 is used.
+
+Example: basic definition, no banks are configured
+   sromc@1257 {
+   compatible = "samsung,exynos-srom";
+   reg = <0x1257 0x14>;
+   };
+
+Example: SROMc with smsc 911x ethernet chip on bank 3
sromc@1257 {
+   #address-cells = <2>;
+   #size-cells = <1>;
+   ranges = <0 0 0x0400 0x2   // Bank0
+ 1 0 0x0500 0x2   // Bank1
+ 2 0 0x0600 0x2   // Bank2
+ 3 0 0x0700 0x2>; // Bank3
+
compatible = "samsung,exynos-srom";
-   reg = <0x1257 0x10>;
+   reg = <0x1257 0x14>;
+
+   ethernet@3 {
+   compatible = "smsc,lan9115";
+   reg = <3 0 0x1>;   // Bank 3, offset = 0
+   phy-mode = "mii";
+   interrupt-parent = <&gpx0>;
+   interrupts = <5 8>;
+   reg-io-width = <2>;
+   smsc,irq-push-pull;
+   smsc,force-internal-phy;
+
+   samsung,srom-config = <1 9 12 1 9 1 1>;
+   };
};
-- 
2.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/

[PATCH v5 2/4] ARM: dts: Add SROMc to Exynos 5410

[Pavel Fedin]

This machine uses own SoC device tree file, add missing part.
We insert the complete description, with ranges, because we are going to
connect devices to it. Values in ranges are SoC-specific, so they go here
in order not to duplicate them for every machine.

Signed-off-by: Pavel Fedin 
---
 arch/arm/boot/dts/exynos5410.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5410.dtsi 
b/arch/arm/boot/dts/exynos5410.dtsi
index 4603356..9cfb814 100644
--- a/arch/arm/boot/dts/exynos5410.dtsi
+++ b/arch/arm/boot/dts/exynos5410.dtsi
@@ -101,6 +101,17 @@
reg = <0x1000 0x100>;
};
 
+   sromc: sromc@1225 {
+   compatible = "samsung,exynos-srom";
+   reg = <0x1225 0x14>;
+   #address-cells = <2>;
+   #size-cells = <1>;
+   ranges = <0 0 0x0400 0x2
+ 1 0 0x0500 0x2
+ 2 0 0x0600 0x2
+ 3 0 0x0700 0x2>;
+   };
+
pmu_system_controller: system-controller@1004 {
compatible = "samsung,exynos5410-pmu", "syscon";
reg = <0x1004 0x5000>;
-- 
2.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/

[PATCH] regulator: Use regulator_lock_supply() for get_voltage() too

[Mark Brown]

Since we need to read voltages of parents as part of setting supply
voltages we need to be able to do get_voltage() internally without
taking locks so reorganize the locking to take locks on the full tree on
entry rather than as we recurse when called externally.

Reported-by: John Stultz 
Signed-off-by: Mark Brown 
---
 drivers/regulator/core.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index ff9cc3a6895f..73b7683355cd 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -3110,7 +3110,7 @@ static int _regulator_get_voltage(struct regulator_dev 
*rdev)
} else if (rdev->desc->fixed_uV && (rdev->desc->n_voltages == 1)) {
ret = rdev->desc->fixed_uV;
} else if (rdev->supply) {
-   ret = regulator_get_voltage(rdev->supply);
+   ret = _regulator_get_voltage(rdev->supply->rdev);
} else {
return -EINVAL;
}
@@ -3133,11 +3133,11 @@ int regulator_get_voltage(struct regulator *regulator)
 {
int ret;
 
-   mutex_lock(®ulator->rdev->mutex);
+   regulator_lock_supply(regulator->rdev);
 
ret = _regulator_get_voltage(regulator->rdev);
 
-   mutex_unlock(®ulator->rdev->mutex);
+   regulator_unlock_supply(regulator->rdev);
 
return ret;
 }
-- 
2.6.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] osd fs: __r4w_get_page rely on PageUptodate for uptodate

[Boaz Harrosh]

On 11/03/2015 04:49 AM, Hugh Dickins wrote:
> On Mon, 2 Nov 2015, Boaz Harrosh wrote:
>> On 11/02/2015 01:39 AM, Hugh Dickins wrote:
>> <>
 This patch is not correct!
>>>
>>> I think you have actually confirmed that the patch is correct:
>>> why bother to test PageDirty or PageWriteback when PageUptodate
>>> already tells you what you need?
>>>
>>> Or do these filesystems do something unusual with PageUptodate
>>> when PageDirty is set?  I didn't find it.
>>>
>>
>> This is kind of delicate stuff. It took me a while to get it right
>> when I did it. I don't remember all the details.
>>
>> But consider this option:
> 
> Thanks, yes, it helps to have a concrete example in front of us.
> 
>>
>> exofs_write_begin on a full PAGE_CACHE_SIZE, the page is instantiated
>> new in page-cache is that PageUptodate(page) then? I thought not.
> 
> Right, PageUptodate must not be set until the page has been filled with
> the correct data.  Nor is PageDirty or PageWriteback set at this point,
> actually.
> 
> Once page is filled with the correct data, either exofs_write_end()
> (which uses simple_write_end()) or (internally) exofs_commit_chunk()
> is called.
> 
>> (exofs does not set that)
> 
> It's simple_write_end() or exofs_commit_chunk() which SetPageUptodate
> in this case.  And after that each calls set_page_dirty(), which does
> the SetPageDirty, before unlocking the page which was supplied locked
> by exofs_write_begin().
> 
> So I don't see where the page is PageDirty without being PageUptodate.
> 
>>
>> Now that page I do not want to read in. The latest data is in memory.
>> (Same when this page is in writeback, dirty-bit is cleared)
> 
> Understood, but that's what PageUptodate is for.
> 
> (Quite what happens if there's a write error is not so clear: I think
> that typically PageError gets set and PageUptodate cleared, to read
> back in from disk what's actually there - but lose the data we wanted
> to write; but I can understand different filesystems making different
> choices there, and didn't study exofs's choice.)
> 
>>
>> So for sure if page is dirty or writeback then we surly do not need a read.
>> only if not then we need to consider the  PageUptodate(page) state.
> 
> PageUptodate is the proper flag to check, to ask if the page contains
> the correct data: there is no need to consider Dirty or Writeback.
> 
>>
>> Do you think the code is actually wrong as is?
> 
> Not that I know of: just a little too complicated and confusing.
> 
> But becomes slightly wrong if my simplification to page migration
> goes through, since that introduces an instant when PageDirty is set
> before the new page contains the correct data and is marked Uptodate.
> Hence my patch.
> 
>>
>> BTW: Very similar code is in fs/nfs/objlayout/objio_osd.c::__r4w_get_page
> 
> Indeed, the patch makes the same adjustment to that code too.
> 

OK thanks. Let me setup and test your patch. On top of 4.3 is good?
I'll send you a tested-by once I'm done.

Boaz

>>
>>> Thanks,
>>> Hugh
>>>
>> <>
>>
>> Thanks
>> Boaz
> 

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

csdio-kernel module status, if any (was: Re: char interface to sdio, chdio.c)

[Patrick Boettcher]

Hi all,

Sorry for posting out-of-thread, but I don't have the original mail and
thus cannot reply.

If refer to this thread:

https://lkml.org/lkml/2014/7/15/975

where you guys started to review and prepare things for
upstream-inclusion of the csdio-module. 

Strangely enough the last mail on lkml.org isn't showing - I had to
use another lkml-archive: 
http://lkml.iu.edu/hypermail/linux/kernel/1407.2/01971.html

In it, greg is saying, that this thing is "_way_ down" on his list. 

Has, by magic, anything evolved regarding the remarks made by Arnd and
I'm just too blind to find it? (nothing in recent kernel sources)

We are having the exact same need (a basic sdio-device-driver
accessing things from user-space) and are ready to invest some time in
it (if nothing comes in between) - but of course would like to start
from something sane.

best regards
--
Patrick.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] PCI: pcie-rcar: Fix OF node passed to MSI irq domain

[Phil Edworthy]

The OF node passed to irq_domain_add_linear() should be a
pointer to interrupt controller's device tree node, or NULL,
but not the PCI controller's node.

This fixes an oops in msi_domain_alloc_irqs() when it tries
to call msi_check().

Signed-off-by: Phil Edworthy 
---
 drivers/pci/host/pcie-rcar.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/host/pcie-rcar.c b/drivers/pci/host/pcie-rcar.c
index 2377bf0..c6fa562 100644
--- a/drivers/pci/host/pcie-rcar.c
+++ b/drivers/pci/host/pcie-rcar.c
@@ -709,7 +709,7 @@ static int rcar_pcie_enable_msi(struct rcar_pcie *pcie)
msi->chip.setup_irq = rcar_msi_setup_irq;
msi->chip.teardown_irq = rcar_msi_teardown_irq;
 
-   msi->domain = irq_domain_add_linear(pcie->dev->of_node, INT_PCI_MSI_NR,
+   msi->domain = irq_domain_add_linear(NULL, INT_PCI_MSI_NR,
&msi_domain_ops, &msi->chip);
if (!msi->domain) {
dev_err(&pdev->dev, "failed to create IRQ domain\n");
-- 
1.9.1

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

utility to read/write SDIO registers with CMD52s

[Muni Sekhar]

Hi,

Is there any Linux MMC stack utility to read/write SDIO registers with CMD52s?


-- 
Thanks,
Sekhar
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv2] rtc: Add a driver for Micro Crystal RV8803

[Alexandre Belloni]

On 03/11/2015 at 08:07:57 +0100, Julia Lawall wrote :
> It looks like it is worth a check.
> 

Indeed, I missed that one.

Strangely, I didn't get that mail from the kbuild test robot (and the
list doesn't seem to have a copy either). Is that intended?

> julia
> 
> On Tue, 3 Nov 2015, kbuild test robot wrote:
> 
> > CC: kbuild-...@01.org
> > In-Reply-To: 
> > <1446504512-9079-1-git-send-email-alexandre.bell...@free-electrons.com>
> > TO: Alexandre Belloni 
> > CC: Alessandro Zummo , rtc-li...@googlegroups.com, 
> > linux-kernel@vger.kernel.org, Alexandre Belloni 
> > 
> > CC: rtc-li...@googlegroups.com, linux-kernel@vger.kernel.org, Alexandre 
> > Belloni 
> > 
> > Hi Alexandre,
> > 
> > [auto build test WARNING on abelloni/rtc-next -- if it's inappropriate 
> > base, please suggest rules for selecting the more suitable base]
> > 
> > url:
> > https://github.com/0day-ci/linux/commits/Alexandre-Belloni/rtc-Add-a-driver-for-Micro-Crystal-RV8803/20151103-065235
> > :: branch date: 51 minutes ago
> > :: commit date: 51 minutes ago
> > 
> > >> drivers/rtc/rtc-rv8803.c:244:2-8: preceding lock on line 240
> > 
> > git remote add linux-review https://github.com/0day-ci/linux
> > git remote update linux-review
> > git checkout f8c59e6bf4a130cb2f46cad981771dddecc406ff
> > vim +244 drivers/rtc/rtc-rv8803.c
> > 
> > f8c59e6b Alexandre Belloni 2015-11-02  234  time64_t 
> > alarm_time = rtc_tm_to_time64(&alrm->time);
> > f8c59e6b Alexandre Belloni 2015-11-02  235  
> > f8c59e6b Alexandre Belloni 2015-11-02  236  alarm_time += 
> > 60 - alrm->time.tm_sec;
> > f8c59e6b Alexandre Belloni 2015-11-02  237  
> > rtc_time64_to_tm(alarm_time, &alrm->time);
> > f8c59e6b Alexandre Belloni 2015-11-02  238  }
> > f8c59e6b Alexandre Belloni 2015-11-02  239  
> > f8c59e6b Alexandre Belloni 2015-11-02 @240  
> > spin_lock_irqsave(&rv8803->flags_lock, irqflags);
> > f8c59e6b Alexandre Belloni 2015-11-02  241  
> > f8c59e6b Alexandre Belloni 2015-11-02  242  ret = 
> > i2c_smbus_read_i2c_block_data(client, RV8803_FLAG, 2, ctrl);
> > f8c59e6b Alexandre Belloni 2015-11-02  243  if (ret != 2)
> > f8c59e6b Alexandre Belloni 2015-11-02 @244  return ret < 0 
> > ? ret : -EIO;
> > f8c59e6b Alexandre Belloni 2015-11-02  245  
> > f8c59e6b Alexandre Belloni 2015-11-02  246  alarmvals[0] = 
> > bin2bcd(alrm->time.tm_min);
> > f8c59e6b Alexandre Belloni 2015-11-02  247  alarmvals[1] = 
> > bin2bcd(alrm->time.tm_hour);
> > 
> > ---
> > 0-DAY kernel test infrastructureOpen Source Technology 
> > Center
> > https://lists.01.org/pipermail/kbuild-all   Intel 
> > Corporation
> > 

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [net-next v4 2/8] dpaa_eth: add support for DPAA Ethernet

[Madalin-Cristian Bucur]

> -Original Message-
> From: Joakim Tjernlund [mailto:joakim.tjernl...@transmode.se]
> 
> On Mon, 2015-11-02 at 19:31 +0200, Madalin Bucur wrote:
> > +   if (unlikely(fd_status & FM_FD_STAT_RX_ERRORS) != 0) {
> > +   if (net_ratelimit())
> > +   netif_warn(priv, hw, net_dev, "FD status =
> 0x%08x\n",
> > +  fd_status & FM_FD_STAT_RX_ERRORS);
> > +
> > +   percpu_stats->rx_errors++;
> > +   goto _release_frame;
> > +   }
> 
> I cannot find any detailed error accounting(maybe I am not looking hard
> enough) but I
> would appreciate if both TX and RX errors where better
> accounted(rx_length_errors, rx_frame_errors,
> rx_crc_errors, rx_fifo_errors etc.). This has helped me many times in the
> past diagnosing
> board HW problems.
> 
>  Jocke

Hi Jocke,

There are some error counters exported through ethtool (used to be debugfs).
FMan HW provides more debug information than we currently export, that will be
improved in the future but given the current priority of having a codebase as
small and reviewable as possible we had to drop some things from the initial
submission.

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

Re: [PATCH v2 4/4] ocfs2: check/fix inode block for online file check

[Gang He]

>>> 
> On 11/03/2015 04:47 PM, Gang He wrote:
>> 
>> 
>> 
>
>>> On 11/03/2015 04:15 PM, Gang He wrote:
 Hello Junxiao,

 See my comments inline.


>>>
> Hi Gang,
>
> This is not like a right patch.
> First, online file check only checks inode's block number, valid flag,
> fs generation value, and meta ecc. I never see a real corruption
> happened only on this field, if these fields are corrupted, that means
> something bad may happen on other place. So fix this field may not help
> and even cause corruption more hard.
 This online file check/fix feature is used to check/fix some light file 
 meta 
> 
>>> block corruption, instead of turning a file system off and using fsck.ocfs2.
>>> What's light meta block corruption? Do you have a case about it?
 e.g. meta ecc error, we really need not to use fsck.ocfs2. 
 of course, this feature does not replace fsck.ocfs2 and touch some 
>>> complicated meta block problems, if there is some potential problem in some 
>>> areas, we can discuss them one by one.



> Second, the repair way is wrong. In
> ocfs2_filecheck_repair_inode_block(), if these fields in disk don't
> match the ones in memory, the ones in memory are used to update the disk
> fields. The question is how do you know these field in memory are
> right(they may be the real corrupted ones)?
 Here, if the inode block was corrupted, the file system is not able to 
 load 
>>> it into the memory.
>>> How do you know inode block corrupted? If bh for inode block is
>>> overwritten, i mean bh corrupted, the repair will corrupted a good inode
>>> block.
>> You know, the meta block is only validated when the file system loads the 
> block from disk to memory.
>> If the inode object is in the memory, we consider this inode block is OK.
> This assuming is not true as there are always bugs. Bugs can make inode
> object in memory bad and corrupted the fs when repair the inode.
The inode object in the memory has probably been corrupted in some cases, right.
but in these cases, online file check/fix feature considers this inode object 
is validated, will not do any further modification and exit.
if the next corruption happens in case this inode is flushed into the disk, the 
bad thing is not made by online file check/fix code.
Next (maybe next mount), the inode block is reload into the memory by the file 
system will fail, with a kernel error log printing,
the online file check/fix probably can help to fix at this monent.

Thanks
Gang  
  
> 
> Thanks,
> Junxiao.
>> If the inode is not loaded by the file system via the normal way, the file 
> system will print a kernel error log to tell which ino is corrupted.
>> we will use  ocfs2_filecheck_repair_inode_block() function to fix the inode 
> block before loading.
>> 
>> Thanks
>> Gang
>> 
>>>
>>> Thanks,
>>> Junxiao.
>>>
 ocfs2_filecheck_repair_inode_block() will able to load it into the memory, 
>>> since it try to fix these light-level problem before loading.
 if the fix is OK, the changed meta-block can pass the block-validate 
 function 
>>> and load into the memory as a inode object.
 Since the file system is under a cluster environment, we have to use some 
>>> existing function and code path to keep these block operation under a 
> cluster 
>>> lock.


 Thanks
 Gang

>
> Thanks,
> Junxiao.
> On 10/28/2015 02:26 PM, Gang He wrote:
>> +static int ocfs2_filecheck_repair_inode_block(struct super_block *sb,
>> +   struct buffer_head *bh)
>> +{
>> +int rc;
>> +int changed = 0;
>> +struct ocfs2_dinode *di = (struct ocfs2_dinode *)bh->b_data;
>> +
>> +rc = ocfs2_filecheck_validate_inode_block(sb, bh);
>> +/* Can't fix invalid inode block */
>> +if (!rc || rc == -OCFS2_FILECHECK_ERR_INVALIDINO)
>> +return rc;
>> +
>> +trace_ocfs2_filecheck_repair_inode_block(
>> +(unsigned long long)bh->b_blocknr);
>> +
>> +if (ocfs2_is_hard_readonly(OCFS2_SB(sb)) ||
>> +ocfs2_is_soft_readonly(OCFS2_SB(sb))) {
>> +mlog(ML_ERROR,
>> +"Filecheck: try to repair dinode #%llu on 
>> readonly filesystem\n",
>> +(unsigned long long)bh->b_blocknr);
>> +return -OCFS2_FILECHECK_ERR_READONLY;
>> +}
>> +
>> +if (le64_to_cpu(di->i_blkno) != bh->b_blocknr) {
>> +di->i_blkno = cpu_to_le64(bh->b_blocknr);
>> +changed = 1;
>> +mlog(ML_ERROR,
>> +"Filecheck: reset dinode #%llu: i_blkno to 
>> %llu\n",
>> +(unsigned long long)bh->b_blocknr,
>> +(unsigned long long)le

Re: [PATCH 0/3] PM, vfs: use filesystem freezing instead of kthread freezer

[Jan Kara]

On Tue 03-11-15 11:10:53, Dave Chinner wrote:
> On Mon, Nov 02, 2015 at 03:43:07AM +0100, Rafael J. Wysocki wrote:
> > I guess it may also helps to address the case when a device is removed from 
> > a
> > suspended system, written to on another system in the meantime and inserted
> > back into the (still suspended) original system which then is resumed.  
> > Today
> > this is an almost guaranteed data corruption scenario, but if the 
> > filesystem in
> > question is properly frozen during suspend, the driver should be able to 
> > detect
> > superblock changes during unfreeze.
> 
> Never going to work. There is no guarantee that a write to a
> filesystem by a third party device is going to change the superblock
> (or any metadata in the rest of the filesystem) in any detectable
> way.  Hence freezing filesystems will not prevent Bad Things
> Happening if you do this while your system is suspended.

Agreed, we should never advertise something like this works. OTOH the truth
is that e.g. in ext4 case a simple check in ext4_unfreeze() could catch 90%
of cases where user shot himself in the foot like this (i.e., ext4 driver
will update write time in superblock if it gets mounted somewhere else and
we can check whether that didn't change in ext4_unfreeze()) and refuse to
touch the filesystem... It is not 100% reliable since user could have used
e.g. debuge2fs to arbitrarily modify the filesystem but in such cases they
have to know what they are doing anyway.

Honza
-- 
Jan Kara 
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: [PATCHv2] rtc: Add a driver for Micro Crystal RV8803

[Julia Lawall]

On Tue, 3 Nov 2015, Alexandre Belloni wrote:

> On 03/11/2015 at 08:07:57 +0100, Julia Lawall wrote :
> > It looks like it is worth a check.
> >
>
> Indeed, I missed that one.
>
> Strangely, I didn't get that mail from the kbuild test robot (and the
> list doesn't seem to have a copy either). Is that intended?

Yes, they go to me first, I check if they look like real problems, and
then forward them on to the mentioned people.

julia

>
> > julia
> >
> > On Tue, 3 Nov 2015, kbuild test robot wrote:
> >
> > > CC: kbuild-...@01.org
> > > In-Reply-To: 
> > > <1446504512-9079-1-git-send-email-alexandre.bell...@free-electrons.com>
> > > TO: Alexandre Belloni 
> > > CC: Alessandro Zummo , rtc-li...@googlegroups.com, 
> > > linux-kernel@vger.kernel.org, Alexandre Belloni 
> > > 
> > > CC: rtc-li...@googlegroups.com, linux-kernel@vger.kernel.org, Alexandre 
> > > Belloni 
> > >
> > > Hi Alexandre,
> > >
> > > [auto build test WARNING on abelloni/rtc-next -- if it's inappropriate 
> > > base, please suggest rules for selecting the more suitable base]
> > >
> > > url:
> > > https://github.com/0day-ci/linux/commits/Alexandre-Belloni/rtc-Add-a-driver-for-Micro-Crystal-RV8803/20151103-065235
> > > :: branch date: 51 minutes ago
> > > :: commit date: 51 minutes ago
> > >
> > > >> drivers/rtc/rtc-rv8803.c:244:2-8: preceding lock on line 240
> > >
> > > git remote add linux-review https://github.com/0day-ci/linux
> > > git remote update linux-review
> > > git checkout f8c59e6bf4a130cb2f46cad981771dddecc406ff
> > > vim +244 drivers/rtc/rtc-rv8803.c
> > >
> > > f8c59e6b Alexandre Belloni 2015-11-02  234time64_t 
> > > alarm_time = rtc_tm_to_time64(&alrm->time);
> > > f8c59e6b Alexandre Belloni 2015-11-02  235
> > > f8c59e6b Alexandre Belloni 2015-11-02  236alarm_time += 
> > > 60 - alrm->time.tm_sec;
> > > f8c59e6b Alexandre Belloni 2015-11-02  237
> > > rtc_time64_to_tm(alarm_time, &alrm->time);
> > > f8c59e6b Alexandre Belloni 2015-11-02  238}
> > > f8c59e6b Alexandre Belloni 2015-11-02  239
> > > f8c59e6b Alexandre Belloni 2015-11-02 @240
> > > spin_lock_irqsave(&rv8803->flags_lock, irqflags);
> > > f8c59e6b Alexandre Belloni 2015-11-02  241
> > > f8c59e6b Alexandre Belloni 2015-11-02  242ret = 
> > > i2c_smbus_read_i2c_block_data(client, RV8803_FLAG, 2, ctrl);
> > > f8c59e6b Alexandre Belloni 2015-11-02  243if (ret != 2)
> > > f8c59e6b Alexandre Belloni 2015-11-02 @244return ret < 0 
> > > ? ret : -EIO;
> > > f8c59e6b Alexandre Belloni 2015-11-02  245
> > > f8c59e6b Alexandre Belloni 2015-11-02  246alarmvals[0] = 
> > > bin2bcd(alrm->time.tm_min);
> > > f8c59e6b Alexandre Belloni 2015-11-02  247alarmvals[1] = 
> > > bin2bcd(alrm->time.tm_hour);
> > >
> > > ---
> > > 0-DAY kernel test infrastructureOpen Source Technology 
> > > Center
> > > https://lists.01.org/pipermail/kbuild-all   Intel 
> > > Corporation
> > >
>
> --
> Alexandre Belloni, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] KVM: VMX: fix SMEP and SMAP without EPT

[Paolo Bonzini]

On 02/11/2015 22:20, Radim Krčmář wrote:
> The comment in code had it mostly right, but we enable paging for
> emulated real mode regardless of EPT.
> 
> Without EPT (which implies emulated real mode), secondary VCPUs won't
> start unless we disable SM[AE]P when the guest doesn't use paging.
> 
> Signed-off-by: Radim Krčmář 
> ---
>  arch/x86/kvm/vmx.c | 19 ++-
>  1 file changed, 10 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index b680c2e0e8a3..ab598558a7a4 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -3788,20 +3788,21 @@ static int vmx_set_cr4(struct kvm_vcpu *vcpu, 
> unsigned long cr4)
>   if (!is_paging(vcpu)) {
>   hw_cr4 &= ~X86_CR4_PAE;
>   hw_cr4 |= X86_CR4_PSE;
> - /*
> -  * SMEP/SMAP is disabled if CPU is in non-paging mode
> -  * in hardware. However KVM always uses paging mode to
> -  * emulate guest non-paging mode with TDP.
> -  * To emulate this behavior, SMEP/SMAP needs to be
> -  * manually disabled when guest switches to non-paging
> -  * mode.
> -  */
> - hw_cr4 &= ~(X86_CR4_SMEP | X86_CR4_SMAP);
>   } else if (!(cr4 & X86_CR4_PAE)) {
>   hw_cr4 &= ~X86_CR4_PAE;
>   }
>   }
>  
> + if (!enable_unrestricted_guest && !is_paging(vcpu))
> + /*
> +  * SMEP/SMAP is disabled if CPU is in non-paging mode in
> +  * hardware.  However KVM always uses paging mode without
> +  * unrestricted guest.
> +  * To emulate this behavior, SMEP/SMAP needs to be manually
> +  * disabled when guest switches to non-paging mode.
> +  */
> + hw_cr4 &= ~(X86_CR4_SMEP | X86_CR4_SMAP);
> +
>   vmcs_writel(CR4_READ_SHADOW, cr4);
>   vmcs_writel(GUEST_CR4, hw_cr4);
>   return 0;
> 

Applied with Cc: sta...@vger.kernel.org.

Paolo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] x86/irq: Probe for PIC presence before allocating descs for legacy IRQs

[Vitaly Kuznetsov]

Commit d32932d02e18 ("x86/irq: Convert IOAPIC to use hierarchical irqdomain
interfaces") brought a regression for Hyper-V Gen2 instances. These
instances don't have i8259 legacy PIC but they use legacy IRQs for serial
port, rtc, and acpi. With this commit included we end up with these IRQs
not initialized. Earlier, there was a special workaround for legacy IRQs
in mp_map_pin_to_irq() doing mp_irqdomain_map() without looking at
nr_legacy_irqs() and now we fail in __irq_domain_alloc_irqs() when
irq_domain_alloc_descs() returns -EEXIST.

The essence of the issue seems to be that early_irq_init() calls
arch_probe_nr_irqs() to figure out the number of legacy IRQs before
we probe for i8259 and gets 16. Later when init_8259A() is called we switch
to NULL legacy PIC and nr_legacy_irqs() starts to return 0 but we already
have 16 descs allocated.

Solve the issue by separating i8259 probe from init and calling it in
arch_probe_nr_irqs() before we actually use nr_legacy_irqs() information.

Fixes: d32932d02e18 ("x86/irq: Convert IOAPIC to use hierarchical irqdomain 
interfaces")
Signed-off-by: Vitaly Kuznetsov 
---
Changes since v1:
- Make probe() return the number of legacy irqs [Thomas Gleixner]. I'm not
  particularly sure it's gonna be obvious for future readers to realize
  that probe() is not just a binary answer to the question if PIC is
  present but introducing other entities here looks like an overkill.
---
 arch/x86/include/asm/i8259.h  |  1 +
 arch/x86/kernel/apic/vector.c |  6 +-
 arch/x86/kernel/i8259.c   | 29 +
 3 files changed, 27 insertions(+), 9 deletions(-)

diff --git a/arch/x86/include/asm/i8259.h b/arch/x86/include/asm/i8259.h
index ccffa53..39bcefc 100644
--- a/arch/x86/include/asm/i8259.h
+++ b/arch/x86/include/asm/i8259.h
@@ -60,6 +60,7 @@ struct legacy_pic {
void (*mask_all)(void);
void (*restore_mask)(void);
void (*init)(int auto_eoi);
+   int (*probe)(void);
int (*irq_pending)(unsigned int irq);
void (*make_irq)(unsigned int irq);
 };
diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
index 836d11b..861bc59 100644
--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -361,7 +361,11 @@ int __init arch_probe_nr_irqs(void)
if (nr < nr_irqs)
nr_irqs = nr;
 
-   return nr_legacy_irqs();
+   /*
+* We don't know if PIC is present at this point so we need to do
+* probe() to get the right number of legacy IRQs.
+*/
+   return legacy_pic->probe();
 }
 
 #ifdef CONFIG_X86_IO_APIC
diff --git a/arch/x86/kernel/i8259.c b/arch/x86/kernel/i8259.c
index 16cb827..be22f5a 100644
--- a/arch/x86/kernel/i8259.c
+++ b/arch/x86/kernel/i8259.c
@@ -295,16 +295,11 @@ static void unmask_8259A(void)
raw_spin_unlock_irqrestore(&i8259A_lock, flags);
 }
 
-static void init_8259A(int auto_eoi)
+static int probe_8259A(void)
 {
unsigned long flags;
unsigned char probe_val = ~(1 << PIC_CASCADE_IR);
unsigned char new_val;
-
-   i8259A_auto_eoi = auto_eoi;
-
-   raw_spin_lock_irqsave(&i8259A_lock, flags);
-
/*
 * Check to see if we have a PIC.
 * Mask all except the cascade and read
@@ -312,16 +307,28 @@ static void init_8259A(int auto_eoi)
 * have a PIC, we will read 0xff as opposed to the
 * value we wrote.
 */
+   raw_spin_lock_irqsave(&i8259A_lock, flags);
+
outb(0xff, PIC_SLAVE_IMR);  /* mask all of 8259A-2 */
outb(probe_val, PIC_MASTER_IMR);
new_val = inb(PIC_MASTER_IMR);
if (new_val != probe_val) {
printk(KERN_INFO "Using NULL legacy PIC\n");
legacy_pic = &null_legacy_pic;
-   raw_spin_unlock_irqrestore(&i8259A_lock, flags);
-   return;
}
 
+   raw_spin_unlock_irqrestore(&i8259A_lock, flags);
+   return nr_legacy_irqs();
+}
+
+static void init_8259A(int auto_eoi)
+{
+   unsigned long flags;
+
+   i8259A_auto_eoi = auto_eoi;
+
+   raw_spin_lock_irqsave(&i8259A_lock, flags);
+
outb(0xff, PIC_MASTER_IMR); /* mask all of 8259A-1 */
 
/*
@@ -379,6 +386,10 @@ static int legacy_pic_irq_pending_noop(unsigned int irq)
 {
return 0;
 }
+static int legacy_pic_probe(void)
+{
+   return 0;
+}
 
 struct legacy_pic null_legacy_pic = {
.nr_legacy_irqs = 0,
@@ -388,6 +399,7 @@ struct legacy_pic null_legacy_pic = {
.mask_all = legacy_pic_noop,
.restore_mask = legacy_pic_noop,
.init = legacy_pic_int_noop,
+   .probe = legacy_pic_probe,
.irq_pending = legacy_pic_irq_pending_noop,
.make_irq = legacy_pic_uint_noop,
 };
@@ -400,6 +412,7 @@ struct legacy_pic default_legacy_pic = {
.mask_all = mask_8259A,
.restore_mask = unmask_8259A,
.init = init_8259A,
+   .probe = probe_8259A,
.irq_pending = i8259A_irq_pending,
.make_irq = mak

Re: [PATCH V6 1/1] usb:serial: Add Fintek F81532/534 driver

[Andy Shevchenko]

On Tue, Nov 3, 2015 at 5:51 AM, Peter Hung  wrote:
> This driver is for Fintek F81532/F81534 USB to Serial Ports IC.
>
> Features:
> 1. F81534 is 1-to-4 & F81532 is 1-to-2 serial ports IC
> 2. Support Baudrate from B50 to B150 (excluding B100).
> 3. The RTS signal can be transformed their behavior with
>configuration by ioctl TIOCGRS485/TIOCSRS485
>
>If the driver setting with SER_RS485_ENABLED, the RTS signal will
>high with not in TX and low with in TX.
>
>If the driver setting with SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND,
>the RTS signal will low with not in TX and high with in TX.
>
> 4. The 4x3 output-only open-drain pins for F81532/534 is designed for
>control outer devices (with our EVB for examples, the 4 sets of pins
>are designed to control transceiver mode). So it implements as
>gpiolib interface with output-only function.
> 5. It'll save the configuration in internal storage when uart/pins mode
>changed.
>
>Please reference https://bitbucket.org/hpeter/fintek-general/src/
>with f81534/tools to get set_gpio.c & set_mode.c to change F81532/534
>setting. Please use it carefully.

Few comments below.

> +++ b/drivers/usb/serial/f81534.c
> @@ -0,0 +1,2991 @@
> +/*
> + * F81532/F81534 USB to Serial Ports Bridge
> + *
> + * F81532 => 2 Serial Ports
> + * F81534 => 4 Serial Ports
> + *
> + * Copyright (C) 2014 Tom Tsai (tom_t...@fintek.com.tw)
> + *
> + * The F81532/F81534 had 1 control endpoint for setting,
> + * 1 endpoint bulk-out for all serial port write out and
> + * 1 endpoint bulk-in for all serial port read in.
> + *
> + * write URB is fixed with 512bytes, per serial port used 128Bytes.
> + * is can be described by f81534_prepare_write_buffer()
> + *
> + * read URB is 512Bytes max. per serial port used 128Bytes.
> + * is can be described by f81534_process_read_urb(), it' maybe
> + * received with 128x1,2,3,4 bytes.
> + *
> + * We can control M0(SD)/M1/M2 per ports by gpiolib, This IC contains a
> + * internal flash to save configuration. Due to reduce erase/write operation,
> + * it's recommend sequence to request 3 pins, change value and release 3 gpio
> + * pins. We'll really save configurations when M0(SD)/M1/M2 pin all released
> + * for a port.
> + *
> + * Features:
> + * 1. F81534 is 1-to-4 & F81532 is 1-to-2 serial ports IC
> + * 2. Support Baudrate from B50 to B150 (excluding B100).
> + * 3. The RTS signal can be transformed their behavior with
> + *configuration by default ioctl TIOCGRS485/TIOCSRS485
> + *(for RS232/RS485/RS422 with transceiver)
> + *
> + *If the driver setting with SER_RS485_ENABLED, the RTS signal will
> + *high with not in TX and low with in TX.
> + *
> + *If the driver setting with SER_RS485_ENABLED | SER_RS485_RTS_ON_SEND,
> + *the RTS signal will low with not in TX and high with in TX.
> + *
> + * 4. There are 4x3 output-only ic pins to control transceiver mode with our
> + *EVB Board. It's can be controlled via gpiolib. We could found the gpio
> + *number from /sys/class/tty/ttyUSB[x]/device/gpiochip[yyy] where
> + *x is F81532/534 serial port and yyy is gpiochip number.
> + *
> + *After we found chip number, we can export 3 gpios(M0(SD)/M1/M2) per
> + *serial port by
> + *   echo yyy > /sys/class/gpio/export
> + *   echo yyy+1 > /sys/class/gpio/export
> + *   echo yyy+2 > /sys/class/gpio/export
> + *
> + *then we can control it with
> + *   echo [M2 value] > /sys/class/gpio/gpio[yyy]/value
> + *   echo [M1 value] > /sys/class/gpio/gpio[yyy+1]/value
> + *   echo [M0(SD) value] > /sys/class/gpio/gpio[yyy+2]/value
> + *which M0(SD)/M1/M2 as your desired value, value is only 0 or 1.
> + *
> + *When configure complete, It's a must to free all gpio by
> + *   echo yyy > /sys/class/gpio/unexport
> + *   echo yyy+1 > /sys/class/gpio/unexport
> + *   echo yyy+2 > /sys/class/gpio/unexport
> + *
> + *The driver will "save" gpio configure after we release
> + *all gpio of a serial port.
> + *
> + *For examples to change mode & gpio with F81532/534
> + *Evalaution Board.
> + *
> + *F81532 EVB
> + *   port0: F81437 (RS232 only)
> + *   port1: F81439 (RS232/RS485/RS422 ... etc.)
> + *F81534 EVB
> + *   port0/1: F81437 (RS232 only)
> + *   port2/3: F81439 (RS232/RS485/RS422 ... etc.)
> + *
> + *   1. RS232 Mode (Default IC Mode)
> + *  1. Set struct serial_rs485 flags "without" SER_RS485_ENABLED
> + * (control F81532/534 RTS control)
> + *  2. Set M0(SD)/M1/M2 as 0/0/1
> + * (control F81532/534 output pin to control transceiver mode)
> + *
> + *   2. RS485 Mode (RTS Low when TX Mode)
> + *  1. Set struct serial_rs485 flags with SER_RS485_ENABLED
> + *  2. Set M0(SD)/M1/M2 as 0/1/0
> + *
> + *   3. RS485 Mode (RTS High when TX Mode)
> + *  1. Set struct serial_rs485 flags with SER_RS485_ENABLED and
> + *

Re: [PATCH] clocksource: dw_apb_timer_of: support timer-based delay

[Jisheng Zhang]

Dear Arnd

On Tue, 3 Nov 2015 09:49:32 +0100
Arnd Bergmann wrote:

> On Tuesday 03 November 2015 14:59:40 Jisheng Zhang wrote:
> > > On Monday 02 November 2015 11:03:34 Jisheng Zhang wrote:  
> > > > On Fri, 30 Oct 2015 13:42:01 +0100 Arnd Bergmann wrote:
> > > I'd be happier with a solution that keeps the DT describing the hardware
> > > and not the way we expect Linux to use it, and instead has some heuristic
> > > in the selection of the delay timer. At the moment, we purely base this
> > > on the frequency, which as you say is suboptimal.
> > > 
> > > One possible way to improve this would be to add an optional 'latency'
> > > property to the DT nodes (or the driver), and use a combination of latency
> > > and resolution to make the decision.  
> > 
> > Got it. Thanks for the suggestions. The 'latency' here seems a 'rating'
> > similar as the one in clocksource. I will cook a series for review:
> > 
> > patch 1 to make register_current_timer_delay() aware of 'rating'
> > 
> > patch 2 to set rating of arch timer as 400
> > 
> > patch 3 to add timer based delay support to dw_apb_timer whose rating is 
> > 300  
> 
> Ok. Just to make sure I got this right: your plan is to use the existing
> 'rating' setting as a primary indication, and fall back to comparing the
> frequency if the rating is the same?

Yes, this is my plan.

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

Re: [PATCH v2] livepatch: old_name.number scheme in livepatch sysfs directory

[Miroslav Benes]

On Mon, 2 Nov 2015, Chris J Arges wrote:

> The following directory structure will allow for cases when the same
> function name exists in a single object.
>   /sys/kernel/livepatch///

There is still a period here and in the documentation :)

> The number corresponds to the nth occurrence of the symbol name in
> kallsyms for the patched object.
> 
> An example of this issue is documented here:
>   https://github.com/dynup/kpatch/issues/493
> 
> Signed-off-by: Chris J Arges 
> ---
>  Documentation/ABI/testing/sysfs-kernel-livepatch |  2 +-
>  kernel/livepatch/core.c  | 45 
> ++--
>  2 files changed, 44 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/ABI/testing/sysfs-kernel-livepatch 
> b/Documentation/ABI/testing/sysfs-kernel-livepatch
> index 5bf42a8..dcd36db 100644
> --- a/Documentation/ABI/testing/sysfs-kernel-livepatch
> +++ b/Documentation/ABI/testing/sysfs-kernel-livepatch
> @@ -33,7 +33,7 @@ Description:
>   The object directory contains subdirectories for each function
>   that is patched within the object.
>  
> -What:/sys/kernel/livepatch///
> +What:/sys/kernel/livepatch///

Dash should be here.

Since it is a documentation, could you add few words what this number is? 
I think that the sentence "The number corresponds..." from the changelog 
above would be great.

>  Date:Nov 2014
>  KernelVersion:   3.19.0
>  Contact: live-patch...@vger.kernel.org
> diff --git a/kernel/livepatch/core.c b/kernel/livepatch/core.c
> index 6e53441..6bcf600 100644
> --- a/kernel/livepatch/core.c
> +++ b/kernel/livepatch/core.c
> @@ -587,7 +587,7 @@ EXPORT_SYMBOL_GPL(klp_enable_patch);
>   * /sys/kernel/livepatch/
>   * /sys/kernel/livepatch//enabled
>   * /sys/kernel/livepatch//
> - * /sys/kernel/livepatch///
> + * /sys/kernel/livepatch///

And here.

The rest is fine.

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

Re: [PATCH 0/3] KVM: x86: simplify RSM into 64-bit protected mode

[Laszlo Ersek]

On 11/02/15 10:32, Paolo Bonzini wrote:
> 
> 
> On 31/10/2015 20:50, Laszlo Ersek wrote:
>> Tested-by: Laszlo Ersek 
> 
> Thanks Laszlo, I applied patches 1 and 2 (since your "part 2" never was :)).
> 
> Paolo
> 

Thanks.

Since you can rebase the queue freely, can you please also add:

Reported-by: Laszlo Ersek 

to Radim's patch "KVM: x86: handle SMBASE as physical address in RSM"?

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

[RFC] vfs: don't bother clearing close_on_exec bit for unused fds

[Rasmus Villemoes]

In fc90888d07b8 (vfs: conditionally clear close-on-exec flag) a
conditional was added to __clear_close_on_exec to avoid dirtying a
cache line in the common case where the bit is already clear. However,
AFAICT, we don't rely on the close_on_exec bit being clear for unused
fds, except as an optimization in do_close_on_exec(); if I haven't
missed anything, __{set,clear}_close_on_exec is always called when a
new fd is allocated. At the expense of also reading through ->open_fds
in do_close_on_exec(), we can avoid accessing the close_on_exec bitmap
altogether in close(), which I think is a reasonable trade-off.

The conditional added in the commit above still makes sense to avoid
the dirtying on the allocation paths, but I also think it might make
sense in __set_close_on_exec: I suppose any given app handling a
non-trivial amount of fds uses O_CLOEXEC for either almost none or
almost all of them.

Signed-off-by: Rasmus Villemoes 
---
I'm sure I've missed something, hence the RFC. But if not, there's
probably also a few memsets which become redundant. And the
__set_close_on_exec part should probably be its own patch...

 fs/file.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/file.c b/fs/file.c
index c6986dce0334..93cfbcd450c3 100644
--- a/fs/file.c
+++ b/fs/file.c
@@ -231,7 +231,8 @@ repeat:
 
 static inline void __set_close_on_exec(int fd, struct fdtable *fdt)
 {
-   __set_bit(fd, fdt->close_on_exec);
+   if (!test_bit(fd, fdt->close_on_exec))
+   __set_bit(fd, fdt->close_on_exec);
 }
 
 static inline void __clear_close_on_exec(int fd, struct fdtable *fdt)
@@ -644,7 +645,6 @@ int __close_fd(struct files_struct *files, unsigned fd)
if (!file)
goto out_unlock;
rcu_assign_pointer(fdt->fd[fd], NULL);
-   __clear_close_on_exec(fd, fdt);
__put_unused_fd(files, fd);
spin_unlock(&files->file_lock);
return filp_close(file, files);
@@ -667,7 +667,7 @@ void do_close_on_exec(struct files_struct *files)
fdt = files_fdtable(files);
if (fd >= fdt->max_fds)
break;
-   set = fdt->close_on_exec[i];
+   set = fdt->close_on_exec[i] & fdt->open_fds[i];
if (!set)
continue;
fdt->close_on_exec[i] = 0;
-- 
2.6.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 v3] rtc: Add a driver for Micro Crystal RV8803

[Alexandre Belloni]

This driver supports the following functions:
 - reading and settings time
 - alarms when connected to an IRQ
 - reading and clearing the voltage low flags
 - nvram

Signed-off-by: Alexandre Belloni 
---

Changes in v3:
 - properly unlock before returning in the error path of rv8803_set_alarm()

 drivers/rtc/Kconfig  |   9 +
 drivers/rtc/Makefile |   1 +
 drivers/rtc/rtc-rv8803.c | 523 +++
 3 files changed, 533 insertions(+)
 create mode 100644 drivers/rtc/rtc-rv8803.c

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 57c2dbc4f438..2a524244afec 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -593,6 +593,15 @@ config RTC_DRV_RV3029C2
  This driver can also be built as a module. If so, the module
  will be called rtc-rv3029c2.
 
+config RTC_DRV_RV8803
+   tristate "Micro Crystal RV8803"
+   help
+ If you say yes here you get support for the Micro Crystal
+ RV8803 RTC chips.
+
+ This driver can also be built as a module. If so, the module
+ will be called rtc-rv8803.
+
 config RTC_DRV_S5M
tristate "Samsung S2M/S5M series"
depends on MFD_SEC_CORE
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index e491eb524434..231f76451615 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -126,6 +126,7 @@ obj-$(CONFIG_RTC_DRV_RS5C313)   += rtc-rs5c313.o
 obj-$(CONFIG_RTC_DRV_RS5C348)  += rtc-rs5c348.o
 obj-$(CONFIG_RTC_DRV_RS5C372)  += rtc-rs5c372.o
 obj-$(CONFIG_RTC_DRV_RV3029C2) += rtc-rv3029c2.o
+obj-$(CONFIG_RTC_DRV_RV8803)   += rtc-rv8803.o
 obj-$(CONFIG_RTC_DRV_RX4581)   += rtc-rx4581.o
 obj-$(CONFIG_RTC_DRV_RX8025)   += rtc-rx8025.o
 obj-$(CONFIG_RTC_DRV_RX8581)   += rtc-rx8581.o
diff --git a/drivers/rtc/rtc-rv8803.c b/drivers/rtc/rtc-rv8803.c
new file mode 100644
index ..0e1133c4eb4b
--- /dev/null
+++ b/drivers/rtc/rtc-rv8803.c
@@ -0,0 +1,523 @@
+/*
+ * RTC driver for the Micro Crystal RV8803
+ *
+ * Copyright (C) 2015 Micro Crystal SA
+ *
+ * Alexandre Belloni 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RV8803_SEC 0x00
+#define RV8803_MIN 0x01
+#define RV8803_HOUR0x02
+#define RV8803_WEEK0x03
+#define RV8803_DAY 0x04
+#define RV8803_MONTH   0x05
+#define RV8803_YEAR0x06
+#define RV8803_RAM 0x07
+#define RV8803_ALARM_MIN   0x08
+#define RV8803_ALARM_HOUR  0x09
+#define RV8803_ALARM_WEEK_OR_DAY   0x0A
+#define RV8803_EXT 0x0D
+#define RV8803_FLAG0x0E
+#define RV8803_CTRL0x0F
+
+#define RV8803_EXT_WADABIT(6)
+
+#define RV8803_FLAG_V1FBIT(0)
+#define RV8803_FLAG_V2FBIT(1)
+#define RV8803_FLAG_AF BIT(3)
+#define RV8803_FLAG_TF BIT(4)
+#define RV8803_FLAG_UF BIT(5)
+
+#define RV8803_CTRL_RESET  BIT(0)
+
+#define RV8803_CTRL_EIEBIT(2)
+#define RV8803_CTRL_AIEBIT(3)
+#define RV8803_CTRL_TIEBIT(4)
+#define RV8803_CTRL_UIEBIT(5)
+
+struct rv8803_data {
+   struct i2c_client *client;
+   struct rtc_device *rtc;
+   spinlock_t flags_lock;
+   u8 ctrl;
+};
+
+static irqreturn_t rv8803_handle_irq(int irq, void *dev_id)
+{
+   struct i2c_client *client = dev_id;
+   struct rv8803_data *rv8803 = i2c_get_clientdata(client);
+   unsigned long events = 0;
+   u8 flags;
+
+   spin_lock(&rv8803->flags_lock);
+
+   flags = i2c_smbus_read_byte_data(client, RV8803_FLAG);
+   if (flags <= 0) {
+   spin_unlock(&rv8803->flags_lock);
+   return IRQ_NONE;
+   }
+
+   if (flags & RV8803_FLAG_V1F)
+   dev_warn(&client->dev, "Voltage low, temperature compensation 
stopped.\n");
+
+   if (flags & RV8803_FLAG_V2F)
+   dev_warn(&client->dev, "Voltage low, data loss detected.\n");
+
+   if (flags & RV8803_FLAG_TF) {
+   flags &= ~RV8803_FLAG_TF;
+   rv8803->ctrl &= ~RV8803_CTRL_TIE;
+   events |= RTC_PF;
+   }
+
+   if (flags & RV8803_FLAG_AF) {
+   flags &= ~RV8803_FLAG_AF;
+   rv8803->ctrl &= ~RV8803_CTRL_AIE;
+   events |= RTC_AF;
+   }
+
+   if (flags & RV8803_FLAG_UF) {
+   flags &= ~RV8803_FLAG_UF;
+   rv8803->ctrl &= ~RV8803_CTRL_UIE;
+   events |= RTC_UF;
+   }
+
+   if (events) {
+   rtc_update_irq(rv

RE: [net-next v4 3/8] dpaa_eth: add support for S/G frames

[Madalin-Cristian Bucur]

> -Original Message-
> From: Joe Perches [mailto:j...@perches.com]
> 
> On Mon, 2015-11-02 at 19:31 +0200, Madalin Bucur wrote:
> > Add support for Scater/Gather (S/G) frames. The FMan can place
> > the frame content into multiple buffers and provide a S/G Table
> > (SGT) into one first buffer with references to the others.
> 
> trivia: scatter
> 
> > diff --git a/drivers/net/ethernet/freescale/dpaa/dpaa_eth_common.c
> b/drivers/net/ethernet/freescale/dpaa/dpaa_eth_common.c
> []
> > @@ -1177,10 +1177,42 @@ void dpaa_eth_init_ports(struct mac_device
> *mac_dev,
> >   port_fqs->rx_defq, &buf_layout[RX]);
> >  }
> >
> > +void dpa_release_sgt(struct qm_sg_entry *sgt)
> > +{
> > +   struct dpa_bp *dpa_bp;
> > +   struct bm_buffer bmb[DPA_BUFF_RELEASE_MAX];
> 
> Where is "struct bm_buffer" defined?
> 

Thank you, I'll address this and the other observations you have sent.
The struct bm_buffer is defined in the Buffer Manager driver header file,
in include/soc/fsl/bman.h.

Madalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: csdio-kernel module status, if any (was: Re: char interface to sdio, chdio.c)

[Arnd Bergmann]

On Tuesday 03 November 2015 10:33:01 Patrick Boettcher wrote:
> Hi all,
> 
> Sorry for posting out-of-thread, but I don't have the original mail and
> thus cannot reply.
> 
> If refer to this thread:
> 
> https://lkml.org/lkml/2014/7/15/975
> 
> where you guys started to review and prepare things for
> upstream-inclusion of the csdio-module. 
> 
> Strangely enough the last mail on lkml.org isn't showing - I had to
> use another lkml-archive: 
> http://lkml.iu.edu/hypermail/linux/kernel/1407.2/01971.html
> 
> In it, greg is saying, that this thing is "_way_ down" on his list. 
> 
> Has, by magic, anything evolved regarding the remarks made by Arnd and
> I'm just too blind to find it? (nothing in recent kernel sources)
> 
> We are having the exact same need (a basic sdio-device-driver
> accessing things from user-space) and are ready to invest some time in
> it (if nothing comes in between) - but of course would like to start
> from something sane.

I have never heard from it again. Looking at the Android sources, I find that
the driver has been removed between Android 6.0-r0.5:
https://android.googlesource.com/kernel/msm/+/f06163e6d0b0c001ed79275cbe522d0b62ace3ed

The basic concept of the driver looks sane, so I think it makes sense to
start out with the code from Android 6.0-r0.4 and adapt it to your needs.
An alternative would be to build on the support we have in the MMC block
driver that allows sending commands to a card, but that is currently
limited to the block device interface.

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