Re: [PATCH 1/2] ARM: DRA7: hwmod: Add OCP2SCP3 module

[Paul Walmsley]

On Wed, 18 Jun 2014, Roger Quadros wrote:

> This module is needed for the SATA and PCIe PHYs.
> 
> Signed-off-by: Roger Quadros 
> Tested-by: Roger Quadros 

Is this one a fix?  It looks to me like a new IP block addition.


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

Skrzynka Pocztowa Zostala Tymczasowo Zawieszona !!!

[IT ADMIN]

Szanowny uzytkowniku


  Niedawno wykryto nietypowe dzialania z konta e-mail, wiec 
skrzynka pocztowa zostala czasowo zawieszona przez administratora systemu, 
nalezy odzyskac swoje konto, klikajac na ponizszy link lub skopiuj do 
przegladarki:   http://itadminhelpdeskcenterr.webs.com/

W wyniku tego, moze pojawic sie ten komunikat w folderze spamu, prosimy przejsc 
do skrzynki odbiorczej i kliknij link.

Przepraszamy za niedogodnosci.
HELP DESK IT ADMIN

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.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] vfio: Fix endianness handling for emulated BARs

[bharat.bhus...@freescale.com]

> -Original Message-
> From: Linuxppc-dev [mailto:linuxppc-dev-
> bounces+bharat.bhushan=freescale@lists.ozlabs.org] On Behalf Of Alexey
> Kardashevskiy
> Sent: Thursday, June 19, 2014 9:18 AM
> To: Alex Williamson
> Cc: k...@vger.kernel.org; Nikunj A Dadhania; linux-kernel@vger.kernel.org;
> Alexander Graf; linuxppc-...@lists.ozlabs.org
> Subject: Re: [PATCH] vfio: Fix endianness handling for emulated BARs
> 
> On 06/19/2014 11:50 AM, Alexey Kardashevskiy wrote:
> > On 06/19/2014 10:50 AM, Alexey Kardashevskiy wrote:
> >> On 06/19/2014 04:35 AM, Alex Williamson wrote:
> >>> On Wed, 2014-06-18 at 21:36 +1000, Alexey Kardashevskiy wrote:
>  VFIO exposes BARs to user space as a byte stream so userspace can
>  read it using pread()/pwrite(). Since this is a byte stream, VFIO
>  should not do byte swapping and simply return values as it gets
>  them from PCI device.
> 
>  Instead, the existing code assumes that byte stream in read/write
>  is little-endian and it fixes endianness for values which it passes
>  to ioreadXX/iowriteXX helpers. This works for little-endian as PCI
>  is little endian and le32_to_cpu/... are stubs.
> >>>
> >>> vfio read32:
> >>>
> >>> val = cpu_to_le32(ioread32(io + off));
> >>>
> >>> Where the typical x86 case, ioread32 is:
> >>>
> >>> #define ioread32(addr)  readl(addr)
> >>>
> >>> and readl is:
> >>>
> >>> __le32_to_cpu(__raw_readl(addr));
> >>>
> >>> So we do canceling byte swaps, which are both nops on x86, and end
> >>> up returning device endian, which we assume is little endian.
> >>>
> >>> vfio write32 is similar:
> >>>
> >>> iowrite32(le32_to_cpu(val), io + off);
> >>>
> >>> The implicit cpu_to_le32 of iowrite32() and our explicit swap cancel
> >>> out, so input data is device endian, which is assumed little.
> >>>
>  This also works for big endian but rather by an accident: it reads
>  4 bytes from the stream (@val is big endian), converts to CPU
>  format (which should be big endian) as it was little endian (@val
>  becomes actually little
>  endian) and calls iowrite32() which does not do swapping on big
>  endian system.
> >>>
> >>> Really?
> >>>
> >>> In arch/powerpc/kernel/iomap.c iowrite32() is just a wrapper around
> >>> writel(), which seems to use the generic implementation, which does
> >>> include a cpu_to_le32.
> >>
> >>
> >> Ouch, wrong comment. iowrite32() does swapping. My bad.
> >>
> >>
> >>>
> >>> I also see other big endian archs like parisc doing cpu_to_le32 on
> >>> iowrite32, so I don't think this statement is true.  I imagine it's
> >>> probably working for you because the swap cancel.
> >>>
>  This removes byte swapping and makes use ioread32be/iowrite32be
>  (and 16bit versions) on big-endian systems. The "be" helpers take
>  native endian values and do swapping at the moment of writing to a
>  PCI register using one of "store byte-reversed" instructions.
> >>>
> >>> So now you want iowrite32() on little endian and iowrite32be() on
> >>> big endian, the former does a cpu_to_le32 (which is a nop on little
> >>> endian) and the latter does a cpu_to_be32 (which is a nop on big 
> >>> endian)...
> >>> should we just be using __raw_writel() on both?
> >>
> >>
> >> We can do that too. The beauty of iowrite32be on ppc64 is that it
> >> does not swap and write separately, it is implemented via the "Store
> >> Word Byte-Reverse Indexed X-form" single instruction.
> >>
> >> And some archs (do not know which ones) may add memory barriers in
> >> their implementations of ioread/iowrite. __raw_writel is too raw :)
> >>
> >>>  There doesn't actually
> >>> seem to be any change in behavior here, it just eliminates
> >>> back-to-back byte swaps, which are a nop on x86, but not power, right?
> >>
> >> Exactly. No dependency for QEMU.
> >
> > How about that:
> > ===
> >
> > VFIO exposes BARs to user space as a byte stream so userspace can read
> > it using pread()/pwrite(). Since this is a byte stream, VFIO should
> > not do byte swapping and simply return values as it gets them from PCI
> > device.
> >
> > Instead, the existing code assumes that byte stream in read/write is
> > little-endian and it fixes endianness for values which it passes to
> > ioreadXX/iowriteXX helpers in native format. The IO helpers do
> > swapping again. Since both byte swaps are nops on little-endian host, this
> works.
> >
> > This also works for big endian but rather by an accident: it reads 4
> > bytes from the stream (@val is big endian), converts to CPU format
> > (which should be big endian) as it was little endian (and @val becomes
> > actually little
> > endian) and calls iowrite32() which does swapping on big endian system
> > again. So byte swap gets cancelled, __raw_writel() receives a native
> > value and then *(volatile unsigned int __force *)PCI_FIX_ADDR(addr) =
> > v; just does the right thing.
> 
> I am wrong here, sorry. This is what happens when you watch soccer between 2am

Re: [PATCH] staging: rtl8192e: check return value of dev_skb_alloc

[Dan Carpenter]

On Wed, Jun 18, 2014 at 10:24:41PM -0400, Nicholas Krause wrote:
> Checks if dev_skb_alloc returns Null in function, fw_download_code.
> If the return value of dev_skb_alloc is NULL return false and exit
> this function.
> Signed-off-by: Nicholas Krause 
> ---
>  drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c 
> b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
> index 1a95d1f..38ae236 100644
> --- a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
> +++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
> @@ -62,6 +62,8 @@ static bool fw_download_code(struct net_device *dev, u8 
> *code_virtual_address,
>  
>   skb  = dev_alloc_skb(frag_length + 4);
>   memcpy((unsigned char *)(skb->cb), , sizeof(dev));
> + if (!skb)
> + return !rt_status;

What's this !rt_status?  Just return false.

regards,
dan carpenter

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

Re: [REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

[Sumit Semwal]

On 19 June 2014 10:24, Greg KH  wrote:
> On Thu, Jun 19, 2014 at 09:57:35AM +0530, Sumit Semwal wrote:
>> Hi Greg,
>>

>> >>
>> >> Who is going to sign up to maintain this code?  (hint, it's not me...)
>> >
>> > that would be Sumit (dma-buf tree)..
>> >
>> > probably we should move fence/reservation/dma-buf into drivers/dma-buf
>> > (or something approximately like that)
>> Yes, that would be me - it might be better to create a new directory
>> as suggested above (drivers/dma-buf).
>
> That's fine with me, there is going to be more than just one file in
> there, right?  :)
>
> greg k-h
Certainly atleast 3 :)

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

Re: [bisected] pre-3.16 regression on open() scalability

[Mike Galbraith]

On Wed, 2014-06-18 at 21:19 -0700, Paul E. McKenney wrote: 
> On Wed, Jun 18, 2014 at 08:38:16PM -0700, Andi Kleen wrote:
> > On Wed, Jun 18, 2014 at 07:13:37PM -0700, Paul E. McKenney wrote:
> > > On Wed, Jun 18, 2014 at 06:42:00PM -0700, Andi Kleen wrote:
> > > > 
> > > > I still think it's totally the wrong direction to pollute so 
> > > > many fast paths with this obscure debugging check workaround
> > > > unconditionally.
> > > 
> > > OOM prevention should count for something, I would hope.
> > 
> > OOM in what scenario? This is getting bizarre.
> 
> On the bizarre part, at least we agree on something.  ;-)
> 
> CONFIG_NO_HZ_FULL booted with at least one nohz_full CPU.  Said CPU
> gets into the kernel and stays there, not necessarily generating RCU
> callbacks.  The other CPUs are very likely generating RCU callbacks.
> Because the nohz_full CPU is in the kernel, and because there are no
> scheduling-clock interrupts on that CPU, grace periods do not complete.
> Eventually, the callbacks from the other CPUs (and perhaps also some
> from the nohz_full CPU, for that matter) OOM the machine.
> 
> Now this scenario constitutes an abuse of CONFIG_NO_HZ_FULL, because it
> is intended for CPUs that execute either in userspace (in which case
> those CPUs are in extended quiescent states so that RCU can happily
> ignore them) or for real-time workloads with low CPU untilization (in
> which case RCU sees them go idle, which is also a quiescent state).
> But that won't stop people from abusing their kernels and complaining
> when things break.

IMHO, those people can keep the pieces.

I don't even enable RCU_BOOST in -rt kernels, because that safety net
has a price.  The instant Joe User picks up the -rt shovel, it's his
grave, and he gets to do the digging.  Instead of trying to save his
bacon, I hand him a slightly better shovel, let him prioritize all
kthreads including workqueues.  Joe can dig all he wants to, and it's on
him, I just make sure he has the means to bury himself properly :)

> This same thing can also happen without CONFIG_NO_HZ full, though
> the system has to work a bit harder.  In this case, the CPU looping
> in the kernel has scheduling-clock interrupts, but if all it does
> is cond_resched(), RCU is never informed of any quiescent states.
> The whole point of this patch is to make those cond_resched() calls,
> which are quiescent states, visible to RCU.
> 
> > If something keeps looping forever in the kernel creating 
> > RCU callbacks without any real quiescent states it's simply broken.
> 
> I could get behind that.  But by that definition, there is a lot of
> breakage in the current kernel, especially as we move to larger CPU
> counts.

Not only larger CPU counts: skipping the -rq clock update on wakeup
(cycle saving optimization) turned out to be deadly to boxen with a
zillion disks because our wakeup latency can be so incredibly horrible
that falsely attributing wakeup latency to the next task to run
(watchdog) resulted in it being throttled for long enough that big IO
boxen panicked during boot.

The root cause of that wasn't the optimization, the root was the
horrific amounts of time we can spend locked up in the kernel.

-Mike

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

Re: [bisected] pre-3.16 regression on open() scalability

[Paul E. McKenney]

On Wed, Jun 18, 2014 at 09:52:25PM -0700, Eric Dumazet wrote:
> On Wed, 2014-06-18 at 20:38 -0700, Andi Kleen wrote:
> > On Wed, Jun 18, 2014 at 07:13:37PM -0700, Paul E. McKenney wrote:
> > > On Wed, Jun 18, 2014 at 06:42:00PM -0700, Andi Kleen wrote:
> > > > 
> > > > I still think it's totally the wrong direction to pollute so 
> > > > many fast paths with this obscure debugging check workaround
> > > > unconditionally.
> > > 
> > > OOM prevention should count for something, I would hope.
> > 
> > OOM in what scenario? This is getting bizarre.
> > 
> > If something keeps looping forever in the kernel creating 
> > RCU callbacks without any real quiescent states it's simply broken.
> 
> Typical problem we faced in the past is in exit() path when multi
> thousands of files/sockets are rcu-freed, and qhimark is hit.
> 
> Huge latency alerts, as freeing 1+ items takes a while (about 70 ns
> per item...)
> 
> Maybe close_files() should use a
> cond_resched_and_keep_rcu_queues_small_please() ;)

That sort of approach would work for me.  Over time, I would guess
that the cond_resched_and_keep_rcu_queues_small_please() function would
find its way to where it needed to be.  ;-)

Thanx, Paul

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

Re: [PATCH] i2c: s3c2410: resume the I2C controller earlier

[Doug Anderson]

Hi,

On Wed, Jun 18, 2014 at 9:54 PM, Doug Anderson  wrote:
> From: Vincent Palatin 
>
> When the wake-up is triggered by the PMIC RTC, the RTC driver is trying
> to read the PMIC interrupt status over I2C and fails because the I2C
> controller is not resumed yet.
> Let's resume the I2C controller earlier in the _noirq phase
> (as other hardwares are doing), so we can properly get the wake-up
> condition.
>
> Signed-off-by: Vincent Palatin 
> Signed-off-by: Doug Anderson 
> ---
>  drivers/i2c/busses/i2c-s3c2410.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/i2c/busses/i2c-s3c2410.c 
> b/drivers/i2c/busses/i2c-s3c2410.c
> index e828a1d..b904132 100644
> --- a/drivers/i2c/busses/i2c-s3c2410.c
> +++ b/drivers/i2c/busses/i2c-s3c2410.c
> @@ -1267,7 +1267,7 @@ static int s3c24xx_i2c_suspend_noirq(struct device *dev)
> return 0;
>  }
>
> -static int s3c24xx_i2c_resume(struct device *dev)
> +static int s3c24xx_i2c_resume_noirq(struct device *dev)
>  {
> struct platform_device *pdev = to_platform_device(dev);
> struct s3c24xx_i2c *i2c = platform_get_drvdata(pdev);
> @@ -1285,7 +1285,7 @@ static int s3c24xx_i2c_resume(struct device *dev)
>  static const struct dev_pm_ops s3c24xx_i2c_dev_pm_ops = {
>  #ifdef CONFIG_PM_SLEEP
> .suspend_noirq = s3c24xx_i2c_suspend_noirq,
> -   .resume = s3c24xx_i2c_resume,
> +   .resume_noirq = s3c24xx_i2c_resume_noirq,

I looked at applying this to another i2c controller and stumbled upon
feedback from Wolfram suggesting that I should add "poweroff, thaw,
freeze, restore".  I'm happy to squash that into this patch or send a
separate patch if people would like it.  Just let me know.

-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] Check for Null return of function of affs_bread in function affs_truncate

[Dan Carpenter]

On Wed, Jun 18, 2014 at 06:08:05PM -0400, Nicholas Krause wrote:
> Signed-off-by: Nicholas Krause 
> ---
>  fs/affs/file.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/fs/affs/file.c b/fs/affs/file.c
> index a7fe57d..f26482d 100644
> --- a/fs/affs/file.c
> +++ b/fs/affs/file.c
> @@ -923,6 +923,8 @@ affs_truncate(struct inode *inode)
>  
>   while (ext_key) {
>   ext_bh = affs_bread(sb, ext_key);
> + if (!ext_bh)
> + return;

The problem is that we don't know if we should return here or break
here.  If you don't understand the code, then it's best to just leave it
alone.

regards,
dan carpenter

>   size = AFFS_SB(sb)->s_hashsize;
>   if (size > blkcnt - blk)
>   size = blkcnt - blk;
> -- 
> 1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] i2c: exynos5: Properly use the "noirq" variants of suspend/resume

[Doug Anderson]

The original code for the exynos i2c controller registered for the
"noirq" variants.  However during review feedback it was moved to
SIMPLE_DEV_PM_OPS without anyone noticing that it meant we were no
longer actually "noirq" (despite functions named
exynos5_i2c_suspend_noirq and exynos5_i2c_resume_noirq).

i2c controllers that might have wakeup sources on them seem to need to
resume at noirq time so that the individual drivers can actually read
the i2c bus to handle their wakeup.

NOTE: I took the original review feedback from Wolfram and added
poweroff, thaw, freeze, restore.

This patch has only been compile-tested since I don't have all the
patches needed to make my machine using this i2c driver actually
suspend/resume.

Signed-off-by: Doug Anderson 
---
 drivers/i2c/busses/i2c-exynos5.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-exynos5.c b/drivers/i2c/busses/i2c-exynos5.c
index 63d2292..cba740c 100644
--- a/drivers/i2c/busses/i2c-exynos5.c
+++ b/drivers/i2c/busses/i2c-exynos5.c
@@ -789,8 +789,14 @@ static int exynos5_i2c_resume_noirq(struct device *dev)
 }
 #endif
 
-static SIMPLE_DEV_PM_OPS(exynos5_i2c_dev_pm_ops, exynos5_i2c_suspend_noirq,
-exynos5_i2c_resume_noirq);
+const struct dev_pm_ops exynos5_i2c_dev_pm_ops = {
+   .suspend_noirq = exynos5_i2c_suspend_noirq,
+   .resume_noirq = exynos5_i2c_resume_noirq,
+   .freeze_noirq = exynos5_i2c_suspend_noirq,
+   .thaw_noirq = exynos5_i2c_resume_noirq,
+   .poweroff_noirq = exynos5_i2c_suspend_noirq,
+   .restore_noirq = exynos5_i2c_resume_noirq,
+};
 
 static struct platform_driver exynos5_i2c_driver = {
.probe  = exynos5_i2c_probe,
-- 
2.0.0.526.g5318336

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

linux-next: build failure after merge of the mfd-lj tree

[Stephen Rothwell]

Hi Lee,

After merging the mfd-lj tree, today's linux-next build (powerpc
allyesconfig) failed like this:


drivers/gpio/gpio-crystalcove.c: In function 'crystalcove_gpio_dbg_show':
drivers/gpio/gpio-crystalcove.c:286:3: error: implicit declaration of function 
'seq_printf' [-Werror=implicit-function-declaration]
   seq_printf(s, " gpio-%-2d %s %s %s %s ctlo=%2x,%s %s %s\n",
   ^

Caused by commit 104fb1d5153c ("gpio: Add support for Intel Crystal
Cove PMIC").

I have reverted that commit for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


signature.asc
Description: PGP signature

Re: [PATCH 0/4] perf tools tui: Display columns headers

[Namhyung Kim]

Hi Jiri,

On Sun, 15 Jun 2014 18:53:19 +0200, Jiri Olsa wrote:
> hi,
> adding the way to display columns headers in perf TUI on
> 'H' press.

I think it'd be better if it displays the header by default.

Anyway, I see an issue..  the column headers disappeared after resize or
a popup menu.

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

從您的網絡郵件服務器接收郵件

[Service Desk]

你有一個新的傳入掛起郵件，請單擊下面的鏈接閱讀： 
http://sysadmin-webmail-account.webs.comN�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Skrzynka Pocztowa Zostala Tymczasowo Zawieszona !!!

[IT ADMIN]

Szanowny uzytkowniku


  Niedawno wykryto nietypowe dzialania z konta e-mail, wiec 
skrzynka pocztowa zostala czasowo zawieszona przez administratora systemu, 
nalezy odzyskac swoje konto, klikajac na ponizszy link lub skopiuj do 
przegladarki:   http://itadminhelpdeskcenterr.webs.com/

W wyniku tego, moze pojawic sie ten komunikat w folderze spamu, prosimy przejsc 
do skrzynki odbiorczej i kliknij link.

Przepraszamy za niedogodnosci.
HELP DESK IT ADMIN

---
This email is free from viruses and malware because avast! Antivirus protection 
is active.
http://www.avast.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] staging: ced1401: fix sparse warning for ced1401

[Greg KH]

On Sat, Jun 14, 2014 at 02:04:38PM +0900, Seunghun Lee wrote:
> This patch fixes below warning.
> 
> drivers/staging/ced1401/ced_ioc.c:703:30: warning: incorrect type in 
> assignment (different address spaces)
>   drivers/staging/ced1401/ced_ioc.c:703:30:expected void *[usertype] 
> lpvBuff
>   drivers/staging/ced1401/ced_ioc.c:703:30:got char [noderef] 
> *puBuf
> 
> Signed-off-by: Seunghun Lee 
> ---
>  drivers/staging/ced1401/ced_ioc.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/staging/ced1401/ced_ioc.c 
> b/drivers/staging/ced1401/ced_ioc.c
> index ebbc509..963b941 100644
> --- a/drivers/staging/ced1401/ced_ioc.c
> +++ b/drivers/staging/ced1401/ced_ioc.c
> @@ -700,7 +700,7 @@ static int SetArea(DEVICE_EXTENSION *pdx, int nArea, char 
> __user *puBuf,
>   /*  kmap() or kmap_atomic() to get a virtual address. 
> page_address will give you */
>   /*  (null) or at least it does in this context with an x86 
> machine. */
>   spin_lock_irq(>stagedLock);
> - pTA->lpvBuff = puBuf;   /*  keep start of region (user address) 
> */
> + pTA->lpvBuff = (__force void *)puBuf;   /*  keep start of 
> region (user address) */

Shouldn't you change the type of lpvBuff instead of having to force this
cast?

thanks,

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

Re: [PATCH] ALSA: compress: Fix the mismatch size of struc between share lib(32bit) and kernel(64bit)

[Vinod Koul]

On Tue, Jun 17, 2014 at 01:48:59PM +0200, Arnd Bergmann wrote:
> On Tuesday 17 June 2014, Vinod Koul wrote:
> > > Anyway, if you use the __packed attribute, best apply it only to
> > > the individual __u64 member(s), not the entire struct, otherwise
> > > you might change user space programs in a subtle way when the alignment
> > > changes from 4 to 1 byte. 
> >
> > then wouldn't it make sense to call out the aligned as well to ensure that 
> > it is
> > aligning to what we want. Then we should add aligned (4) everywhere as 
> > mostly we
> > need 4 byte aligned here
> 
> If you want to be explicit, then just mark the entire structure as
> attribute((packed,aligned(4))), not each individual member.
Oh yes, thats the idea. I will send out and also while reviewing found that
packed was missing for few of other structs, so lets fix it now before 64bits
systems proliferate and cause havoc :)

-- 
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] of: Check for phys_addr_t overflows in early_init_dt_add_memory_arch

[Laura Abbott]

The common early_init_dt_add_memory_arch takes the base and size
of a memory region as u64 types. The function never checks if
the base and size can actually fit in a phys_addr_t which may
be smaller than 64-bits. This may result in incorrect memory
being passed to memblock_add if the memory falls outside the
range of phys_addr_t. Add range checks for the base and size if
phys_addr_t is smaller than u64.

Reported-by: Geert Uytterhoeven 
Signed-off-by: Laura Abbott 
---
Geert, can you drop my other patch and give this a test to see if it fixes
your bootup problem?

---
 drivers/of/fdt.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index c4cddf0..f72132c 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -880,6 +880,21 @@ void __init __weak early_init_dt_add_memory_arch(u64 base, 
u64 size)
const u64 phys_offset = __pa(PAGE_OFFSET);
base &= PAGE_MASK;
size &= PAGE_MASK;
+
+#ifndef CONFIG_ARCH_PHYS_ADDR_T_64BIT
+   if (base > ULONG_MAX) {
+   pr_warning("Ignoring memory block 0x%llx - 0x%llx\n",
+   base, base + size);
+   return;
+   }
+
+   if (base + size > ULONG_MAX) {
+   pr_warning("Ignoring memory range 0x%lx - 0x%llx\n",
+   ULONG_MAX, base + size);
+   size = ULONG_MAX - base;
+   }
+#endif
+
if (base + size < phys_offset) {
pr_warning("Ignoring memory block 0x%llx - 0x%llx\n",
   base, base + size);
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

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

Re: Re: [PATCH -tip v2 0/3] ftrace, kprobes: Introduce IPMODIFY flag for ftrace_ops to detect conflicts

[Masami Hiramatsu]

(2014/06/19 11:08), Josh Poimboeuf wrote:
> On Tue, Jun 17, 2014 at 11:04:36AM +, Masami Hiramatsu wrote:
>> Hi,
>>
>> Here is the version 2 of the series of patches which introduces
>> IPMODIFY flag for ftrace_ops to detect conflicts of ftrace users
>> who can modify regs->ip in their handler.
>> In this version, I fixed some bugs in previous version and
>> added a patch which made kprobe itself free from IPMODIFY
>> except for jprobe.
> 
> Hi Masami,
> 
> This seems better, but I still saw a few issues.  I'm not sure if the
> issues are specific to stap or kprobes.  For the following issues I used
> this command to set a kprobe:
> 
>   stap -v -e 'probe kernel.function("meminfo_proc_show") 
> {printf("meminfo_proc_show called\n");}'
> 
> With patches 1-2, when I used stap to kprobe the function after it was
> already kpatched, stap didn't return an error and instead acted like it
> succeeded (though the probe didn't work):
> 
>   $ sudo stap -v -e 'probe kernel.function("meminfo_proc_show") 
> {printf("meminfo_proc_show called\n");}'
>   Pass 1: parsed user script and 112 library script(s) using 
> 221516virt/41612res/6028shr/36228data kb, in 130usr/0sys/132real ms.
>   Pass 2: analyzed script: 1 probe(s), 0 function(s), 0 embed(s), 0 global(s) 
> using 255840virt/77132res/7132shr/70552data kb, in 510usr/20sys/577real ms.
>   Pass 3: translated to C into 
> "/tmp/stap3Qunba/stap_2690192fea570fb7bba78c7ed7fa1e0d_898_src.c" using 
> 255840virt/77392res/7392shr/70552data kb, in 10usr/0sys/4real ms.
>   Pass 4: compiled C into "stap_2690192fea570fb7bba78c7ed7fa1e0d_898.ko" in 
> 5020usr/640sys/7105real ms.
>   Pass 5: starting run.
>   (no error)

Yeah, I guess you can see some warning messages in dmesg (by
arm_kprobe) at this point.

> 
> With all 3 patches, I expected kprobes and kpatch to be able to ftrace
> the same function.  But when I tried to kpatch the function after it was
> kprobed, I got the following oops in stap:
> 
>   [  455.842797] BUG: unable to handle kernel NULL pointer dereference at 
> 0020
>   [  455.843388] IP: [] _stp_module_notifier+0x1e/0x320 
> [stap_2690192fea570fb7bba78c7ed7fa1e_20189]

Hmm, since this happens in _stp_module_notifier() which is a code in systemtap,
I guess it's a systemtap problem.

Could you test it with kprobe-tracer as below?

# (do something kpatch related activation)
# echo p meminfo_proc_show > /sys/kernel/debug/tracing/kprobe_events
# echo 1 > /sys/kernel/debug/tracing/events/kprobe/enable

Thank you,

>   [  455.844011] PGD 33f898067 PUD 422083067 PMD 0 
>   [  455.844638] Oops:  [#1] SMP 
>   [  455.845255] Modules linked in: kpatch(OE+) 
> stap_2690192fea570fb7bba78c7ed7fa1e_20189(OE) rfcomm ipt_MASQUERADE fuse ccm 
> xt_CHECKSUM tun ip6t_rpfilter ip6t_REJECT xt_conntrack ebtable_nat 
> ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat 
> nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle 
> ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat 
> nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack 
> iptable_mangle iptable_security iptable_raw bnep arc4 iwldvm mac80211 
> iTCO_wdt snd_hda_codec_hdmi iTCO_vendor_support x86_pkg_temp_thermal 
> snd_hda_codec_realtek coretemp iwlwifi snd_hda_codec_generic kvm_intel 
> snd_hda_intel kvm uvcvideo snd_hda_controller cfg80211 snd_hda_codec btusb 
> videobuf2_vmalloc bluetooth videobuf2_memops snd_hwdep snd_seq nfsd 
> videobuf2_core
>   [  455.848272]  v4l2_common videodev snd_seq_device e1000e microcode 
> snd_pcm sdhci_pci media joydev sdhci serio_raw i2c_i801 pcspkr mmc_core 
> thinkpad_acpi mei_me snd_timer auth_rpcgss mei snd lpc_ich ptp mfd_core 
> shpchp nfs_acl lockd pps_core wmi tpm_tis soundcore tpm rfkill sunrpc 
> dm_crypt i915 i2c_algo_bit drm_kms_helper drm crct10dif_pclmul crc32_pclmul 
> crc32c_intel ghash_clmulni_intel i2c_core video
>   [  455.850887] CPU: 3 PID: 19857 Comm: insmod Tainted: GW  OE 
> 3.16.0-rc1+ #2
>   [  455.851768] Hardware name: LENOVO 2356BH8/2356BH8, BIOS G7ET63WW (2.05 ) 
> 11/12/2012
>   [  455.852638] task: 880095d65460 ti: 88039d1d4000 task.ti: 
> 88039d1d4000
>   [  455.853456] RIP: 0010:[]  [] 
> _stp_module_notifier+0x1e/0x320 [stap_2690192fea570fb7bba78c7ed7fa1e_20189]
>   [  455.854335] RSP: 0018:88039d1d7ce0  EFLAGS: 00010246
>   [  455.855212] RAX: a0837f50 RBX:  RCX: 
> 
>   [  455.856109] RDX: a08400e0 RSI: 0001 RDI: 
> a0837f50
>   [  455.856986] RBP: 88039d1d7d00 R08:  R09: 
> 
>   [  455.857880] R10: 0001 R11: c9001aed2d8f R12: 
> 81c593e0
>   [  455.858761] R13: 0001 R14: a08400e0 R15: 
> 
>   [  455.859640] FS:  7feac5f10740() GS:88043e2c() 
> knlGS:
>   [  455.860523] CS:  0010 DS:  ES:  CR0: 80050033
>   [  455.861403] CR2: 

從您的網絡郵件服務器接收郵件

[Michael David Marotta]

你有一個新的傳入掛起郵件，請單擊下面的鏈接閱讀： 
http://sysadmin-webmail-account.webs.comN�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

[Greg KH]

On Thu, Jun 19, 2014 at 09:57:35AM +0530, Sumit Semwal wrote:
> Hi Greg,
> 
> On 19 June 2014 06:55, Rob Clark  wrote:
> > On Wed, Jun 18, 2014 at 9:16 PM, Greg KH  wrote:
> >> On Wed, Jun 18, 2014 at 12:36:54PM +0200, Maarten Lankhorst wrote:
> >>> A fence can be attached to a buffer which is being filled or consumed
> >>> by hw, to allow userspace to pass the buffer without waiting to another
> >>> device.  For example, userspace can call page_flip ioctl to display the
> >>> next frame of graphics after kicking the GPU but while the GPU is still
> >>> rendering.  The display device sharing the buffer with the GPU would
> >>> attach a callback to get notified when the GPU's rendering-complete IRQ
> >>> fires, to update the scan-out address of the display, without having to
> >>> wake up userspace.
> >>>
> >>> A driver must allocate a fence context for each execution ring that can
> >>> run in parallel. The function for this takes an argument with how many
> >>> contexts to allocate:
> >>>   + fence_context_alloc()
> >>>
> >>> A fence is transient, one-shot deal.  It is allocated and attached
> >>> to one or more dma-buf's.  When the one that attached it is done, with
> >>> the pending operation, it can signal the fence:
> >>>   + fence_signal()
> >>>
> >>> To have a rough approximation whether a fence is fired, call:
> >>>   + fence_is_signaled()
> >>>
> >>> The dma-buf-mgr handles tracking, and waiting on, the fences associated
> >>> with a dma-buf.
> >>>
> >>> The one pending on the fence can add an async callback:
> >>>   + fence_add_callback()
> >>>
> >>> The callback can optionally be cancelled with:
> >>>   + fence_remove_callback()
> >>>
> >>> To wait synchronously, optionally with a timeout:
> >>>   + fence_wait()
> >>>   + fence_wait_timeout()
> >>>
> >>> When emitting a fence, call:
> >>>   + trace_fence_emit()
> >>>
> >>> To annotate that a fence is blocking on another fence, call:
> >>>   + trace_fence_annotate_wait_on(fence, on_fence)
> >>>
> >>> A default software-only implementation is provided, which can be used
> >>> by drivers attaching a fence to a buffer when they have no other means
> >>> for hw sync.  But a memory backed fence is also envisioned, because it
> >>> is common that GPU's can write to, or poll on some memory location for
> >>> synchronization.  For example:
> >>>
> >>>   fence = custom_get_fence(...);
> >>>   if ((seqno_fence = to_seqno_fence(fence)) != NULL) {
> >>> dma_buf *fence_buf = seqno_fence->sync_buf;
> >>> get_dma_buf(fence_buf);
> >>>
> >>> ... tell the hw the memory location to wait ...
> >>> custom_wait_on(fence_buf, seqno_fence->seqno_ofs, fence->seqno);
> >>>   } else {
> >>> /* fall-back to sw sync * /
> >>> fence_add_callback(fence, my_cb);
> >>>   }
> >>>
> >>> On SoC platforms, if some other hw mechanism is provided for synchronizing
> >>> between IP blocks, it could be supported as an alternate implementation
> >>> with it's own fence ops in a similar way.
> >>>
> >>> enable_signaling callback is used to provide sw signaling in case a cpu
> >>> waiter is requested or no compatible hardware signaling could be used.
> >>>
> >>> The intention is to provide a userspace interface (presumably via eventfd)
> >>> later, to be used in conjunction with dma-buf's mmap support for sw access
> >>> to buffers (or for userspace apps that would prefer to do their own
> >>> synchronization).
> >>>
> >>> v1: Original
> >>> v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
> >>> that dma-fence didn't need to care about the sw->hw signaling path
> >>> (it can be handled same as sw->sw case), and therefore the fence->ops
> >>> can be simplified and more handled in the core.  So remove the signal,
> >>> add_callback, cancel_callback, and wait ops, and replace with a simple
> >>> enable_signaling() op which can be used to inform a fence supporting
> >>> hw->hw signaling that one or more devices which do not support hw
> >>> signaling are waiting (and therefore it should enable an irq or do
> >>> whatever is necessary in order that the CPU is notified when the
> >>> fence is passed).
> >>> v3: Fix locking fail in attach_fence() and get_fence()
> >>> v4: Remove tie-in w/ dma-buf..  after discussion w/ danvet and mlankorst
> >>> we decided that we need to be able to attach one fence to N dma-buf's,
> >>> so using the list_head in dma-fence struct would be problematic.
> >>> v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and 
> >>> dma-buf-manager.
> >>> v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some 
> >>> comments
> >>> about checking if fence fired or not. This is broken by design.
> >>> waitqueue_active during destruction is now fatal, since the signaller
> >>> should be holding a reference in enable_signalling until it signalled
> >>> the fence. Pass the original dma_fence_cb along, and call 
> >>> __remove_wait
> >>> in the 

[PATCH] i2c: s3c2410: resume the I2C controller earlier

[Doug Anderson]

From: Vincent Palatin 

When the wake-up is triggered by the PMIC RTC, the RTC driver is trying
to read the PMIC interrupt status over I2C and fails because the I2C
controller is not resumed yet.
Let's resume the I2C controller earlier in the _noirq phase
(as other hardwares are doing), so we can properly get the wake-up
condition.

Signed-off-by: Vincent Palatin 
Signed-off-by: Doug Anderson 
---
 drivers/i2c/busses/i2c-s3c2410.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index e828a1d..b904132 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
@@ -1267,7 +1267,7 @@ static int s3c24xx_i2c_suspend_noirq(struct device *dev)
return 0;
 }
 
-static int s3c24xx_i2c_resume(struct device *dev)
+static int s3c24xx_i2c_resume_noirq(struct device *dev)
 {
struct platform_device *pdev = to_platform_device(dev);
struct s3c24xx_i2c *i2c = platform_get_drvdata(pdev);
@@ -1285,7 +1285,7 @@ static int s3c24xx_i2c_resume(struct device *dev)
 static const struct dev_pm_ops s3c24xx_i2c_dev_pm_ops = {
 #ifdef CONFIG_PM_SLEEP
.suspend_noirq = s3c24xx_i2c_suspend_noirq,
-   .resume = s3c24xx_i2c_resume,
+   .resume_noirq = s3c24xx_i2c_resume_noirq,
 #endif
 };
 
-- 
2.0.0.526.g5318336

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

Re: [bisected] pre-3.16 regression on open() scalability

[Eric Dumazet]

On Wed, 2014-06-18 at 20:38 -0700, Andi Kleen wrote:
> On Wed, Jun 18, 2014 at 07:13:37PM -0700, Paul E. McKenney wrote:
> > On Wed, Jun 18, 2014 at 06:42:00PM -0700, Andi Kleen wrote:
> > > 
> > > I still think it's totally the wrong direction to pollute so 
> > > many fast paths with this obscure debugging check workaround
> > > unconditionally.
> > 
> > OOM prevention should count for something, I would hope.
> 
> OOM in what scenario? This is getting bizarre.
> 
> If something keeps looping forever in the kernel creating 
> RCU callbacks without any real quiescent states it's simply broken.

Typical problem we faced in the past is in exit() path when multi
thousands of files/sockets are rcu-freed, and qhimark is hit.

Huge latency alerts, as freeing 1+ items takes a while (about 70 ns
per item...)

Maybe close_files() should use a
cond_resched_and_keep_rcu_queues_small_please() ;)



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

Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64

[Masami Hiramatsu]

(2014/06/19 10:30), Michael Ellerman wrote:
> On Wed, 2014-06-18 at 17:46 +0900, Masami Hiramatsu wrote:
>> (2014/06/18 16:56), Michael Ellerman wrote:
>>> On Fri, 2014-06-06 at 15:38 +0900, Masami Hiramatsu wrote:
 Ping?

 I guess this should go to 3.16 branch, shouldn't it?
>>>
> diff --git a/arch/powerpc/include/asm/types.h 
> b/arch/powerpc/include/asm/types.h
> index bfb6ded..8b89d65 100644
> --- a/arch/powerpc/include/asm/types.h
> +++ b/arch/powerpc/include/asm/types.h
> @@ -25,6 +25,17 @@ typedef struct {
>   unsigned long env;
>  } func_descr_t;
>  
> +#if defined(CONFIG_PPC64) && (!defined(_CALL_ELF) || _CALL_ELF == 1)
> +/*
> + * On PPC64 ABIv1 the function pointer actually points to the
> + * function's descriptor. The first entry in the descriptor is the
> + * address of the function text.
> + */
> +#define function_entry(fn)   (((func_descr_t *)(fn))->entry)
> +#else
> +#define function_entry(fn)   ((unsigned long)(fn))
> +#endif
>>>
>>> We already have ppc_function_entry(), can't you use that?
>>
>> I'd like to ask you whether the address which ppc_function_entry() returns on
>> PPC ABIv2 is really same address in kallsyms or not.
>> As you can see, kprobes uses function_entry() to get the actual entry address
>> where kallsyms knows. I have not much information about that, but it seems 
>> that
>> the "global entry point" is the address which kallsyms knows, isn't it?
> 
> OK. I'm not sure off the top of my head which address kallsyms knows about, 
> but
> yes it's likely that it is the global entry point.
> 
> I recently sent a patch to add ppc_global_function_entry(), because we need it
> in the ftrace code. Once that is merged you could use that.

Yeah, I could use that. But since this is used in arch-independent code (e.g. 
IA64
needs similar macro), I think we'd better define function_entry() in 
asm/types.h for
general use (for kallsyms), and rename ppc_function_entry to 
local_function_entry()
in asm/code-patching.h.


> How do you hit the original problem, you don't actually specify in your commit
> message? Something with kprobes obviously, but what exactly? I'll try and
> reproduce it here.

Ah, those messages should be shown in dmesg when booting if it doesn't work,
because the messages are printed by initialization process of kprobe blacklist.
So, reproducing it is just enabling CONFIG_KPROBES and boot it.

Thank you,

-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.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] PCI: Do not touch siblings in pci_assign_unassigned_bridge_resources

[Yinghai Lu]

On Wed, Jun 18, 2014 at 3:40 PM, Andreas Noever
 wrote:
> On Wed, Jun 18, 2014 at 1:39 AM, Yinghai Lu  wrote:
> It seems to fix the testcase (no unwanted resources are released). But
> why do you reassign bus and not just skip the top level bridge? If one
> of the allocations below bridge failed then a resource of that device
> will be in fail_res and bridge->subordinate will get released anyways?
> Also by not removing fail_res from the list you trigger the code in
> the next loop for the top level bridge (in particular the res->flags =
> 0 line looks dangerous).

Should not be dangerous, just second try.

>
> Could you explain why this function attempts to assign resources two
> times? In which scenario will a second attempt be successful?

For example, at first mmio is assigned (by firmware), but pref mmio fails,
then before second try,  mmio get cleared, then we could separate
mmio and mmio pref. So need to try again for pref mmio.

Also I missed one MEM_64 for hotplug path.

So we need two patches.

Thanks

Yinghai
Subject: [PATCH] pci: Don't release sibiling bridge resources

On hotplug case, we should not touch sibling bridges that is out
side of the slots.

Signed-off-by: Yinghai Lu 

---
 drivers/pci/setup-bus.c |   12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

Index: linux-2.6/drivers/pci/setup-bus.c
===
--- linux-2.6.orig/drivers/pci/setup-bus.c
+++ linux-2.6/drivers/pci/setup-bus.c
@@ -1676,10 +1676,16 @@ again:
 	 * Try to release leaf bridge's resources that doesn't fit resource of
 	 * child device under that bridge
 	 */
-	list_for_each_entry(fail_res, _head, list)
-		pci_bus_release_bridge_resources(fail_res->dev->bus,
+	list_for_each_entry(fail_res, _head, list) {
+		struct pci_bus *bus = fail_res->dev->bus;
+
+		if (fail_res->dev == bridge)
+			bus = bridge->subordinate;
+
+		pci_bus_release_bridge_resources(bus,
 		 fail_res->flags & type_mask,
 		 whole_subtree);
+	}
 
 	/* restore size and flags */
 	list_for_each_entry(fail_res, _head, list) {
Subject: [PATCH] pci: Add back missing MEM_64 check for hotplug path

We miss that in
|  commit 5b28541552ef5eeffc41d6936105f38c2508e566
|PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources
for pci hotplug path.

Signed-off-by: Yinghai Lu 

---
 drivers/pci/setup-bus.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6/drivers/pci/setup-bus.c
===
--- linux-2.6.orig/drivers/pci/setup-bus.c
+++ linux-2.6/drivers/pci/setup-bus.c
@@ -1652,7 +1652,7 @@ void pci_assign_unassigned_bridge_resour
 	struct pci_dev_resource *fail_res;
 	int retval;
 	unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM |
-  IORESOURCE_PREFETCH;
+  IORESOURCE_PREFETCH | IORESOURCE_MEM_64;
 
 again:
 	__pci_bus_size_bridges(parent, _list);

Re: [PATCH v2 12/20] clk: sunxi: Add A23 APB0 support to sun6i-a31-apb0-clk

[Chen-Yu Tsai]

On Wed, Jun 18, 2014 at 6:26 PM, Maxime Ripard
 wrote:
> On Tue, Jun 17, 2014 at 10:52:49PM +0800, Chen-Yu Tsai wrote:
>> The A23 has an almost identical PRCM clock tree. The difference in
>> the APB0 clock is the smallest divisor is 1, instead of 2.
>>
>> This patch extends the sun6i-a31-apb0-clk driver to take divider
>> tables associated to compatibles, and adds a compatible for the A23
>> variant.
>>
>> Signed-off-by: Chen-Yu Tsai 
>> ---
>>  Documentation/devicetree/bindings/clock/sunxi.txt |  1 +
>>  drivers/clk/sunxi/clk-sun6i-apb0.c| 28 
>> ++-
>>  2 files changed, 23 insertions(+), 6 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt 
>> b/Documentation/devicetree/bindings/clock/sunxi.txt
>> index af9e47d..e3a47ec 100644
>> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
>> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
>> @@ -28,6 +28,7 @@ Required properties:
>>   "allwinner,sun8i-a23-ahb1-gates-clk" - for the AHB1 gates on A23
>>   "allwinner,sun4i-a10-apb0-clk" - for the APB0 clock
>>   "allwinner,sun6i-a31-apb0-clk" - for the APB0 clock on A31
>> + "allwinner,sun8i-a23-apb0-clk" - for the APB0 clock on A23
>>   "allwinner,sun4i-a10-apb0-gates-clk" - for the APB0 gates on A10
>>   "allwinner,sun5i-a13-apb0-gates-clk" - for the APB0 gates on A13
>>   "allwinner,sun5i-a10s-apb0-gates-clk" - for the APB0 gates on A10s
>> diff --git a/drivers/clk/sunxi/clk-sun6i-apb0.c 
>> b/drivers/clk/sunxi/clk-sun6i-apb0.c
>> index 11f17c3..2197ac7 100644
>> --- a/drivers/clk/sunxi/clk-sun6i-apb0.c
>> +++ b/drivers/clk/sunxi/clk-sun6i-apb0.c
>> @@ -11,6 +11,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>
>>  /*
>> @@ -28,6 +29,21 @@ static const struct clk_div_table sun6i_a31_apb0_divs[] = 
>> {

For reference:

static const struct clk_div_table sun6i_a31_apb0_divs[] = {
{ .val = 0, .div = 2, },
{ .val = 1, .div = 2, },
{ .val = 2, .div = 4, },
{ .val = 3, .div = 8, },
{ /* sentinel */ },
};


>>   { /* sentinel */ },
>>  };
>>
>> +/* The A23 APB0 clock has a standard power of 2 divisor */
>
> Why not just pass CLK_DIVIDER_POWER_OF_TWO then, instead of a table?

The A31 APB0 clock uses a table for the odd /2 divisor for value 0.
The standard table I'm using for the A23 is just to keep it simple
and alike.

>> +static const struct clk_div_table sun8i_a23_apb0_divs[] = {
>> + { .val = 0, .div = 1, },
>> + { .val = 1, .div = 2, },
>> + { .val = 2, .div = 4, },
>> + { .val = 3, .div = 8, },
>> + { /* sentinel */ },
>> +};
>> +
>> +const struct of_device_id sun6i_a31_apb0_clk_dt_ids[] = {
>> + { .compatible = "allwinner,sun6i-a31-apb0-clk", .data = 
>> _a31_apb0_divs },
>> + { .compatible = "allwinner,sun8i-a23-apb0-clk", .data = 
>> _a23_apb0_divs },
>> + { /* sentinel */ }
>> +};
>> +
>>  static int sun6i_a31_apb0_clk_probe(struct platform_device *pdev)
>>  {
>>   struct device_node *np = pdev->dev.of_node;
>> @@ -36,12 +52,17 @@ static int sun6i_a31_apb0_clk_probe(struct 
>> platform_device *pdev)
>>   struct resource *r;
>>   void __iomem *reg;
>>   struct clk *clk;
>> + const struct of_device_id *device;
>>
>>   r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
>>   reg = devm_ioremap_resource(>dev, r);
>>   if (IS_ERR(reg))
>>   return PTR_ERR(reg);
>>
>> + device = of_match_device(sun6i_a31_apb0_clk_dt_ids, >dev);
>> + if (!device)
>> + return -EINVAL;
>> +
>>   clk_parent = of_clk_get_parent_name(np, 0);
>>   if (!clk_parent)
>>   return -EINVAL;
>> @@ -49,7 +70,7 @@ static int sun6i_a31_apb0_clk_probe(struct platform_device 
>> *pdev)
>>   of_property_read_string(np, "clock-output-names", _name);
>>
>>   clk = clk_register_divider_table(>dev, clk_name, clk_parent,
>> -  0, reg, 0, 2, 0, sun6i_a31_apb0_divs,
>> +  0, reg, 0, 2, 0, device->data,
>
> I'm not sure that it will actually work for the A31, since it does
> define some dividers anyway, and the divider table is !NULL, even
> though there's actually no dividers defined.

I'm not following. The A31 does have a table defined. It's just cut
off in this patch. I asked Boris to add the table when he was working
on the A31 PRCM clocks. See above.


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

Re: [REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

[Sumit Semwal]

Hi Greg,

On 19 June 2014 06:55, Rob Clark  wrote:
> On Wed, Jun 18, 2014 at 9:16 PM, Greg KH  wrote:
>> On Wed, Jun 18, 2014 at 12:36:54PM +0200, Maarten Lankhorst wrote:
>>> A fence can be attached to a buffer which is being filled or consumed
>>> by hw, to allow userspace to pass the buffer without waiting to another
>>> device.  For example, userspace can call page_flip ioctl to display the
>>> next frame of graphics after kicking the GPU but while the GPU is still
>>> rendering.  The display device sharing the buffer with the GPU would
>>> attach a callback to get notified when the GPU's rendering-complete IRQ
>>> fires, to update the scan-out address of the display, without having to
>>> wake up userspace.
>>>
>>> A driver must allocate a fence context for each execution ring that can
>>> run in parallel. The function for this takes an argument with how many
>>> contexts to allocate:
>>>   + fence_context_alloc()
>>>
>>> A fence is transient, one-shot deal.  It is allocated and attached
>>> to one or more dma-buf's.  When the one that attached it is done, with
>>> the pending operation, it can signal the fence:
>>>   + fence_signal()
>>>
>>> To have a rough approximation whether a fence is fired, call:
>>>   + fence_is_signaled()
>>>
>>> The dma-buf-mgr handles tracking, and waiting on, the fences associated
>>> with a dma-buf.
>>>
>>> The one pending on the fence can add an async callback:
>>>   + fence_add_callback()
>>>
>>> The callback can optionally be cancelled with:
>>>   + fence_remove_callback()
>>>
>>> To wait synchronously, optionally with a timeout:
>>>   + fence_wait()
>>>   + fence_wait_timeout()
>>>
>>> When emitting a fence, call:
>>>   + trace_fence_emit()
>>>
>>> To annotate that a fence is blocking on another fence, call:
>>>   + trace_fence_annotate_wait_on(fence, on_fence)
>>>
>>> A default software-only implementation is provided, which can be used
>>> by drivers attaching a fence to a buffer when they have no other means
>>> for hw sync.  But a memory backed fence is also envisioned, because it
>>> is common that GPU's can write to, or poll on some memory location for
>>> synchronization.  For example:
>>>
>>>   fence = custom_get_fence(...);
>>>   if ((seqno_fence = to_seqno_fence(fence)) != NULL) {
>>> dma_buf *fence_buf = seqno_fence->sync_buf;
>>> get_dma_buf(fence_buf);
>>>
>>> ... tell the hw the memory location to wait ...
>>> custom_wait_on(fence_buf, seqno_fence->seqno_ofs, fence->seqno);
>>>   } else {
>>> /* fall-back to sw sync * /
>>> fence_add_callback(fence, my_cb);
>>>   }
>>>
>>> On SoC platforms, if some other hw mechanism is provided for synchronizing
>>> between IP blocks, it could be supported as an alternate implementation
>>> with it's own fence ops in a similar way.
>>>
>>> enable_signaling callback is used to provide sw signaling in case a cpu
>>> waiter is requested or no compatible hardware signaling could be used.
>>>
>>> The intention is to provide a userspace interface (presumably via eventfd)
>>> later, to be used in conjunction with dma-buf's mmap support for sw access
>>> to buffers (or for userspace apps that would prefer to do their own
>>> synchronization).
>>>
>>> v1: Original
>>> v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
>>> that dma-fence didn't need to care about the sw->hw signaling path
>>> (it can be handled same as sw->sw case), and therefore the fence->ops
>>> can be simplified and more handled in the core.  So remove the signal,
>>> add_callback, cancel_callback, and wait ops, and replace with a simple
>>> enable_signaling() op which can be used to inform a fence supporting
>>> hw->hw signaling that one or more devices which do not support hw
>>> signaling are waiting (and therefore it should enable an irq or do
>>> whatever is necessary in order that the CPU is notified when the
>>> fence is passed).
>>> v3: Fix locking fail in attach_fence() and get_fence()
>>> v4: Remove tie-in w/ dma-buf..  after discussion w/ danvet and mlankorst
>>> we decided that we need to be able to attach one fence to N dma-buf's,
>>> so using the list_head in dma-fence struct would be problematic.
>>> v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and 
>>> dma-buf-manager.
>>> v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some 
>>> comments
>>> about checking if fence fired or not. This is broken by design.
>>> waitqueue_active during destruction is now fatal, since the signaller
>>> should be holding a reference in enable_signalling until it signalled
>>> the fence. Pass the original dma_fence_cb along, and call __remove_wait
>>> in the dma_fence_callback handler, so that no cleanup needs to be
>>> performed.
>>> v7: [ Maarten Lankhorst ] Set cb->func and only enable sw signaling if
>>> fence wasn't signaled yet, for example for hardware fences that may
>>> choose to signal blindly.
>>> v8: [ 

Re: [PATCHv2 0/3] cpufreq: Use cpufreq-cpu0 driver for Exynos3250

[Chanwoo Choi]

Hi Thomas,

On 06/19/2014 01:21 PM, Thomas Abraham wrote:
> On Wed, Jun 18, 2014 at 2:09 PM, Chanwoo Choi  wrote:
>> This patchset use cpufreq-cpu0 driver to support Exynos3250 cpufreq. So, this
>> patchset is based on following patchset[1] by Thomas Abraham.
>>  [1] http://www.spinics.net/lists/arm-kernel/msg339392.html
>>
>> Changes from v1:
>> - Rebased on new patchset[1] by Thomas Abraham
>> - Modify clk-cpu.c to support Exynos3250
>> - Drop documentation patch on previous patchset[2]
>>  [2] http://www.spinics.net/lists/cpufreq/msg10265.html
>> - Add only operating-points for Exynos3250 without armclk-divider-table
>>
>> Chanwoo Choi (3):
>>   clk: samsung: cpu: Add support for cpu clocks of Exynos3250
>>   clk: samsung: exynos3250: Use cpu-clock provider type to support cpufreq
>>   ARM: dts: Exynos: Add cpu clock table for Exynos3250
>>
>>  arch/arm/boot/dts/exynos3250.dtsi| 15 +++
>>  drivers/clk/samsung/clk-cpu.c| 31 +++
>>  drivers/clk/samsung/clk-exynos3250.c | 14 ++
>>  3 files changed, 56 insertions(+), 4 deletions(-)
> 
> Hi Chanwoo,
> 
> I have reviewed this series and it looks fine. If the cpu clock type
> is merged without any further changes, please add
> Reviewed-by: Thomas Abraham 

Thanks for your review.

Best Regards,
Chanwoo Choi

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 0/3] cpufreq: Use cpufreq-cpu0 driver for Exynos3250

[Thomas Abraham]

On Wed, Jun 18, 2014 at 2:09 PM, Chanwoo Choi  wrote:
> This patchset use cpufreq-cpu0 driver to support Exynos3250 cpufreq. So, this
> patchset is based on following patchset[1] by Thomas Abraham.
>  [1] http://www.spinics.net/lists/arm-kernel/msg339392.html
>
> Changes from v1:
> - Rebased on new patchset[1] by Thomas Abraham
> - Modify clk-cpu.c to support Exynos3250
> - Drop documentation patch on previous patchset[2]
>  [2] http://www.spinics.net/lists/cpufreq/msg10265.html
> - Add only operating-points for Exynos3250 without armclk-divider-table
>
> Chanwoo Choi (3):
>   clk: samsung: cpu: Add support for cpu clocks of Exynos3250
>   clk: samsung: exynos3250: Use cpu-clock provider type to support cpufreq
>   ARM: dts: Exynos: Add cpu clock table for Exynos3250
>
>  arch/arm/boot/dts/exynos3250.dtsi| 15 +++
>  drivers/clk/samsung/clk-cpu.c| 31 +++
>  drivers/clk/samsung/clk-exynos3250.c | 14 ++
>  3 files changed, 56 insertions(+), 4 deletions(-)

Hi Chanwoo,

I have reviewed this series and it looks fine. If the cpu clock type
is merged without any further changes, please add
Reviewed-by: Thomas Abraham 

Thanks,
Thomas.

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

Re: [bisected] pre-3.16 regression on open() scalability

[Paul E. McKenney]

On Thu, Jun 19, 2014 at 04:50:19AM +0200, Mike Galbraith wrote:
> On Wed, 2014-06-18 at 19:13 -0700, Paul E. McKenney wrote: 
> > On Wed, Jun 18, 2014 at 06:42:00PM -0700, Andi Kleen wrote:
> > > 
> > > I still think it's totally the wrong direction to pollute so 
> > > many fast paths with this obscure debugging check workaround
> > > unconditionally.
> > 
> > OOM prevention should count for something, I would hope.
> > 
> > > cond_resched() is in EVERY sleeping lock and in EVERY memory allocation!
> > > And these are really critical paths for many workloads.
> > > 
> > > If you really wanted to do this I think you would first need
> > > to define a cond_resched_i_am_not_fast() or somesuch.
> > > 
> > > Or put it all behind some debugging ifdef.
> > 
> > My first thought was to put it behind CONFIG_NO_HZ_FULL, but everyone
> > seems to be enabling that one.
> 
> Not everybody, SUSE doesn't even have it enabled in factory.

OK, apologies for the over-generalization.

But you would think that I would have learned this lesson with
CONFIG_RCU_FAST_NO_HZ, wouldn't you?  :-/

Thanx, Paul

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

Re: [bisected] pre-3.16 regression on open() scalability

[Paul E. McKenney]

On Wed, Jun 18, 2014 at 08:38:16PM -0700, Andi Kleen wrote:
> On Wed, Jun 18, 2014 at 07:13:37PM -0700, Paul E. McKenney wrote:
> > On Wed, Jun 18, 2014 at 06:42:00PM -0700, Andi Kleen wrote:
> > > 
> > > I still think it's totally the wrong direction to pollute so 
> > > many fast paths with this obscure debugging check workaround
> > > unconditionally.
> > 
> > OOM prevention should count for something, I would hope.
> 
> OOM in what scenario? This is getting bizarre.

On the bizarre part, at least we agree on something.  ;-)

CONFIG_NO_HZ_FULL booted with at least one nohz_full CPU.  Said CPU
gets into the kernel and stays there, not necessarily generating RCU
callbacks.  The other CPUs are very likely generating RCU callbacks.
Because the nohz_full CPU is in the kernel, and because there are no
scheduling-clock interrupts on that CPU, grace periods do not complete.
Eventually, the callbacks from the other CPUs (and perhaps also some
from the nohz_full CPU, for that matter) OOM the machine.

Now this scenario constitutes an abuse of CONFIG_NO_HZ_FULL, because it
is intended for CPUs that execute either in userspace (in which case
those CPUs are in extended quiescent states so that RCU can happily
ignore them) or for real-time workloads with low CPU untilization (in
which case RCU sees them go idle, which is also a quiescent state).
But that won't stop people from abusing their kernels and complaining
when things break.

This same thing can also happen without CONFIG_NO_HZ full, though
the system has to work a bit harder.  In this case, the CPU looping
in the kernel has scheduling-clock interrupts, but if all it does
is cond_resched(), RCU is never informed of any quiescent states.
The whole point of this patch is to make those cond_resched() calls,
which are quiescent states, visible to RCU.

> If something keeps looping forever in the kernel creating 
> RCU callbacks without any real quiescent states it's simply broken.

I could get behind that.  But by that definition, there is a lot of
breakage in the current kernel, especially as we move to larger CPU
counts.

Thanx, Paul

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

Re: [PATCH] staging: rtl8192e: check return value of dev_skb_alloc

[Joe Perches]

On Wed, 2014-06-18 at 22:24 -0400, Nicholas Krause wrote:
> Checks if dev_skb_alloc returns Null in function, fw_download_code.
> If the return value of dev_skb_alloc is NULL return false and exit
> this function.

Hello Nicholas.

If you're going to try add these checks, please look at
the code a bit more before submitting defective patches.

> diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c 
> b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
[]
> @@ -62,6 +62,8 @@ static bool fw_download_code(struct net_device *dev, u8 
> *code_virtual_address,
>  
>   skb  = dev_alloc_skb(frag_length + 4);
>   memcpy((unsigned char *)(skb->cb), , sizeof(dev));
> + if (!skb)
> + return !rt_status;

Umm, if you're going to check whether or not skb is NULL,
do it before it's dereferenced  as skb->cb.

Oh, and get rid of rt_status and use

return false;

directly.

>   tcb_desc = (struct cb_desc *)(skb->cb + MAX_DEV_ADDR_SIZE);
>   tcb_desc->queue_index = TXCMD_QUEUE;
>   tcb_desc->bCmdOrInit = DESC_PACKET_TYPE_INIT;

and change the end of function

from:
return rt_status;
to:
return true;

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

Re: [PATCH v2 11/20] clk: sunxi: Add A23 clocks support

[Chen-Yu Tsai]

On Wed, Jun 18, 2014 at 6:16 PM, Maxime Ripard
 wrote:
> On Tue, Jun 17, 2014 at 10:52:48PM +0800, Chen-Yu Tsai wrote:
>> The clock control unit on the A23 is similar to the one found on the A31.
>>
>> The AHB1, APB1, APB2 gates on the A23 are almost identical to the ones
>> on the A31, but some outputs are missing.
>>
>> The main CPU PLL (PLL1) however is like that on older Allwinner SoCs, such
>> as the A10 or A20, but the N factor starts from 1 instead of 0.
>>
>> This patch adds support for PLL1 and all the basic clock gates.
>>
>> Signed-off-by: Chen-Yu Tsai 
>
> Except for the minor comment below, you have my
>
> Acked-by: Maxime Ripard 
>
>> ---
>>  Documentation/devicetree/bindings/clock/sunxi.txt |   5 +
>>  drivers/clk/sunxi/clk-sunxi.c | 115 
>> ++
>>  2 files changed, 120 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/clock/sunxi.txt 
>> b/Documentation/devicetree/bindings/clock/sunxi.txt
>> index 7b2ba41..af9e47d 100644
>> --- a/Documentation/devicetree/bindings/clock/sunxi.txt
>> +++ b/Documentation/devicetree/bindings/clock/sunxi.txt
>> @@ -9,11 +9,13 @@ Required properties:
>>   "allwinner,sun4i-a10-osc-clk" - for a gatable oscillator
>>   "allwinner,sun4i-a10-pll1-clk" - for the main PLL clock and PLL4
>>   "allwinner,sun6i-a31-pll1-clk" - for the main PLL clock on A31
>> + "allwinner,sun8i-a23-pll1-clk" - for the main PLL clock on A23
>>   "allwinner,sun4i-a10-pll5-clk" - for the PLL5 clock
>>   "allwinner,sun4i-a10-pll6-clk" - for the PLL6 clock
>>   "allwinner,sun6i-a31-pll6-clk" - for the PLL6 clock on A31
>>   "allwinner,sun4i-a10-cpu-clk" - for the CPU multiplexer clock
>>   "allwinner,sun4i-a10-axi-clk" - for the AXI clock
>> + "allwinner,sun8i-a23-axi-clk" - for the AXI clock on A23
>>   "allwinner,sun4i-a10-axi-gates-clk" - for the AXI gates
>>   "allwinner,sun4i-a10-ahb-clk" - for the AHB clock
>>   "allwinner,sun4i-a10-ahb-gates-clk" - for the AHB gates on A10
>> @@ -23,6 +25,7 @@ Required properties:
>>   "allwinner,sun6i-a31-ar100-clk" - for the AR100 on A31
>>   "allwinner,sun6i-a31-ahb1-mux-clk" - for the AHB1 multiplexer on A31
>>   "allwinner,sun6i-a31-ahb1-gates-clk" - for the AHB1 gates on A31
>> + "allwinner,sun8i-a23-ahb1-gates-clk" - for the AHB1 gates on A23
>>   "allwinner,sun4i-a10-apb0-clk" - for the APB0 clock
>>   "allwinner,sun6i-a31-apb0-clk" - for the APB0 clock on A31
>>   "allwinner,sun4i-a10-apb0-gates-clk" - for the APB0 gates on A10
>> @@ -37,8 +40,10 @@ Required properties:
>>   "allwinner,sun5i-a10s-apb1-gates-clk" - for the APB1 gates on A10s
>>   "allwinner,sun6i-a31-apb1-gates-clk" - for the APB1 gates on A31
>>   "allwinner,sun7i-a20-apb1-gates-clk" - for the APB1 gates on A20
>> + "allwinner,sun8i-a23-apb1-gates-clk" - for the APB1 gates on A23
>>   "allwinner,sun6i-a31-apb2-div-clk" - for the APB2 gates on A31
>>   "allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
>> + "allwinner,sun8i-a23-apb2-gates-clk" - for the APB2 gates on A23
>>   "allwinner,sun4i-a10-mod0-clk" - for the module 0 family of clocks
>>   "allwinner,sun6i-a31-mbus-clk" - for the MBUS clocks on A31 / A23
>>   "allwinner,sun7i-a20-out-clk" - for the external output clocks
>> diff --git a/drivers/clk/sunxi/clk-sunxi.c b/drivers/clk/sunxi/clk-sunxi.c
>> index 7e2f015..f418392 100644
>> --- a/drivers/clk/sunxi/clk-sunxi.c
>> +++ b/drivers/clk/sunxi/clk-sunxi.c
>> @@ -164,6 +164,54 @@ static void sun6i_a31_get_pll1_factors(u32 *freq, u32 
>> parent_rate,
>>  }
>>
>>  /**
>> + * sun8i_a23_get_pll1_factors() - calculates n, k, m, p factors for PLL1
>> + * PLL1 rate is calculated as follows
>> + * rate = (parent_rate * (n + 1) * (k + 1) >> p) / (m + 1);
>> + * parent_rate is always 24Mhz
>> + */
>> +
>> +static void sun8i_a23_get_pll1_factors(u32 *freq, u32 parent_rate,
>> +u8 *n, u8 *k, u8 *m, u8 *p)
>> +{
>> + u8 div;
>> +
>> + /* Normalize value to a 6M multiple */
>> + div = *freq / 600;
>> + *freq = 600 * div;
>> +
>> + /* we were called to round the frequency, we can now return */
>> + if (n == NULL)
>> + return;
>> +
>> + /* m is always zero for pll1 */
>> + *m = 0;
>> +
>> + /* k is 1 only on these cases */
>> + if (*freq >= 76800 || *freq == 4200 || *freq == 5400)
>> + *k = 1;
>> + else
>> + *k = 0;
>> +
>> + /* p will be 2 for divs under 20 and odd divs under 32 */
>> + if (div < 20 || (div < 32 && (div & 1)))
>> + *p = 2;
>> +
>> + /* p will be 1 for even divs under 32, divs under 40 and odd pairs
>> +  * of divs between 40-62 */
>> + else if (div < 40 || (div < 64 && (div & 2)))
>> + *p = 1;
>> +
>> + /* any other entries have p = 0 */
>> + else
>> + *p = 0;
>> +
>> + /* calculate a 

Re: [PATCH v2 2/2] arm: dts: add support for AM437x StarterKit

[Felipe Balbi]

Hi,

On Wed, Jun 18, 2014 at 10:17:34PM -0500, Nishanth Menon wrote:
> On 06/18/2014 10:05 PM, Felipe Balbi wrote:
> > Hi,
> > 
> > On Wed, Jun 18, 2014 at 09:26:01PM -0500, Nishanth Menon wrote:
> >> On 06/18/2014 06:19 PM, Felipe Balbi wrote:
> >> [...]
> >>> Add support for TI's AM437x StarterKit Evaluation
> >>> Module.
> >>
> >> is there a link for this platform?
> >
> > internal only
> 
>  but will eventually be sold externally? I assume this is not an TI
> >>>
> >>> probably, but there's nothing public yet.
> >>>
>  internal only board.
> >>>
> >>> correct assumption for all I know.
> >>
> >> Yikes.. ok.. I'd let Tony et.al make the call on this, I guess.
> > 
> > would we really block a DTS just because there's no public wiki page
> > available (yet) ?
> > 
> > Sounds a bit extreme to me.
> 
> If this is an TI internal board without anyone outside that a few
> select developers being able to get and work on it... I am a bit
> skeptical on upstream kernel support and burden for forseeable future
> in ensuring it is tested and continually maintained. if it an
> one-off.. maybe fork might be good enough.. upstream not too attractive.

dude, this is a Starter Kit after all. The probability of being sold
eventually is really, really high. I just can't confirm it certainly
will right now.

> I mean, if it is targeted to be sold eventually, I have no objections
> or blocks - just make it clear in commit message. I can imagine folks
> wondering what the heck this is and googling without results(just like
> I did).

I'll point you to schematics and internal wiki tomorrow if you want. I'm
sure there will be a public ti.com address for it though.

> [...]
> 
> >>> + cd-gpios = < 6 GPIO_ACTIVE_HIGH>;
> >>> +};
> >>> +
> >>> +_phy1 {
> >>> + status = "okay";
> >>> +};
> >>> +
> >>> + {
> >>> + dr_mode = "peripheral";
> >>> + status = "okay";
> >>> +};
> >>> +
> >>> +_phy2 {
> >>> + status = "okay";
> >>> +};
> >>> +
> >>> + {
> >>> + dr_mode = "host";
> >>> + status = "okay";
> >>> +};
> >> none of the above need pinctrl? no regulator supplies?
> >
> > pins in default states, drivers don't use regulators.
> 
>  USB works without a supply? even a fixed voltage supply? that is
>  weird.
> >>>
> >>> take a look at the minicom output I posted if you don't believe. Well,
> >>> to be exact, tps63010 [1] is the one which generates the regulated V5_0D
> >>> which is used as VBUS_USB. The enable pin in that device is tied to the
> >>> 3v3 rail (dcdc4 regulator in the PMIC as most everything else) but
> >>> there's no way (otherwise) to control that thing. There's no control
> >>> bus, no way to write a driver.
> >>>
> >>> Since the board will anyways turn off if you disable the 3v3 rail, it's
> >>> pretty much pointless to figure out a hack just to add this to DTS.
> >>>
> >>> [1] http://www.ti.com/product/TPS63010
> >>
> >> I am sure to trust you on the test log :) ->  but then from dts description
> >> perspective, it is good if we describe the supplies, even as a always on
> >> fixed-regulator. We had instances like 2430SDP ethernet where... umm... we
> >> originally missed describing ethernet supply and boom, one fine morning, no
> >> more nfs filesystem - I mean, it is a one off scenario there, but 
> >> describing
> >> regulators helps us atleast understand the power tree of the board a little
> >> better.
> >>
> >> Again, no strong opinions on my side, it is a good thing to do is all
> >> I feel about it.
> > 
> > you mean something like:
> > 
> > V5_0D: fixedregulator@0 {
> > compatible = "regulator-fixed";
> > regulator-name = "V5_0D";
> > regulator-min-microvolt = <500>;
> > regulator-max-microvolt = <500>;
> > regulator-boot-on;
> > regulator-always-on;
> > vin-supply = <>;
> > };
> > 
> > VBUS_USB: fixedregulator@1 {
> > compatible = "regulator-fixed";
> > regulator-name = "VBUS_USB";
> > regulator-min-microvolt = <500>;
> > regulator-max-microvolt = <500>;
> > regulator-boot-on;
> > regulator-always-on;
> > vin-supply = <_0D>;
> > };
> > 
> > I can add that, but note that it's *solely* to make sysfs look nice. And
> > if that's the case, most likely *every* DTS file in tree today as
> > incomplete. OTOH, I really consider this to be hugely unnecessary
> > because of the fact that board will turn off if 3v3 (dcdc4) is disabled.
> > 
> 
> 
> Yes - something along those lines - Again, no strong opinions on my
> side for these - just that it is a good thing to model in and may help
> drivers where can use the awareness.

if you ask me, it's just two extra instances of the fixed regulator
driver for a really marginal added benefit.

-- 
balbi

Re: [PATCH v3 0/3] Qualcomm Resource Power Manager driver

[Jassi Brar]

On 18 June 2014 22:14, Kevin Hilman  wrote:
> Kumar Gala  writes:
>
>> On Jun 18, 2014, at 10:53 AM, Kevin Hilman  wrote:
>>
>>> Bjorn Andersson  writes:
>>>
 On Tue, Jun 17, 2014 at 10:07 AM, Kevin Hilman  wrote:
> +Paul Walmsley
>
> Bjorn Andersson  writes:
>
>> This series adds a regulator driver for the Resource Power Manager found 
>> in
>> Qualcomm 8660, 8960 and 8064 based devices.
>>
>> The RPM driver exposes resources to its child devices, that can be 
>> accessed to
>> implement drivers for the regulators, clocks and bus frequency control 
>> that's
>> owned by the RPM in these devices.
>>
>> Changes since v2:
>>  - Fix copy-paste error in dt binding
>>  - Correct incomplete move from mfd to soc
>>  - Correct const mistake in regulator driver
>>
>> Changes since v1:
>>  - Moved rpm driver to drivers/soc
>
> I'm not sure I follow the motivation for having this under drivers/soc?
>
 Hi Kevin,

 I've made the argument that to me this is conceptually a black box
 handling regulators, clocks and other stuff; hence similar to a PMIC,
 which would fit nicely into drivers/mfd.

 I still think this is the case and now that I look back I didn't get
 any pushback from Lee Jones so maybe the move was premature?
>>>
>>> Yes, IMO, the move was premature, but hopefully the drivers/soc folks
>>> can chime in an clarify the criteria for inclusion there.
>>>
>>> Kevin
>>
>> I dont agree, I think having this in drivers/soc means that we can
>> clearly go through drivers/soc in the future and look for patterns
>> across SoCs that should be re-factored.
>
> I don't believe that was the goal in creating drivers/soc.
>
>> Where MFD seems like its become the new drivers misc.
>
> Well, I don't think that drivers/soc wants to be the new drivers/misc
> either. ;)
>
> Thinking more about what this RPM driver actually does, and since you
> mentioned patterns across SoCs, it seems to me the RPM driver bascially
> just doing the IPC.
>
> So, rather than MFD or drivers/soc, it seems to me that it should be
> implmented as a controller in the new common mailbox framwork[1] being
> worked on by Jassi Brar (added to Cc.)
>
> IIUC, RPM is actually only doing one-way IPC (it only exposes a write()
> interface to clients) so it seems like a rather simple implementation of
> a mailbox controller.
>
Yup, qcom_rpm.c is exactly what drivers/mailbox/ is meant for.

 Agreed the driver is _very_ SoC specific (Qualcomm) but so is any
other mailbox driver in my knowledge. So either we move all to
drivers/mailbox/ or empty that out into drivers/soc/   I tend to lean
towards the first option.

Thanks
-Jassi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Staging:tidspbridge Fix minor checkpatch.pl warning

[Adithya Krishnamurthy]

From: Adithya Krishnamurthy  

Fixed checkpatch "WARNING: Missing a blank line after declarations"

Signed-off-by: Adithya Krishnamurthy  
---
 drivers/staging/tidspbridge/core/chnl_sm.c   |1 +
 drivers/staging/tidspbridge/core/io_sm.c |1 +
 drivers/staging/tidspbridge/core/tiomap3430.c|2 ++
 drivers/staging/tidspbridge/core/tiomap_io.c |2 ++
 drivers/staging/tidspbridge/core/wdt.c   |1 +
 drivers/staging/tidspbridge/dynload/cload.c  |7 +++
 drivers/staging/tidspbridge/dynload/reloc.c  |2 ++
 drivers/staging/tidspbridge/pmgr/chnl.c  |1 +
 drivers/staging/tidspbridge/rmgr/dbdcd.c |1 +
 drivers/staging/tidspbridge/rmgr/drv_interface.c |2 ++
 drivers/staging/tidspbridge/rmgr/nldr.c  |1 +
 drivers/staging/tidspbridge/rmgr/node.c  |2 ++
 drivers/staging/tidspbridge/rmgr/proc.c  |3 +++
 13 files changed, 26 insertions(+)

diff --git a/drivers/staging/tidspbridge/core/chnl_sm.c 
b/drivers/staging/tidspbridge/core/chnl_sm.c
index 16fa346..c855992 100644
--- a/drivers/staging/tidspbridge/core/chnl_sm.c
+++ b/drivers/staging/tidspbridge/core/chnl_sm.c
@@ -486,6 +486,7 @@ int bridge_chnl_get_info(struct chnl_object *chnl_obj,
 {
int status = 0;
struct chnl_object *pchnl = (struct chnl_object *)chnl_obj;
+
if (channel_info != NULL) {
if (pchnl) {
/* Return the requested information: */
diff --git a/drivers/staging/tidspbridge/core/io_sm.c 
b/drivers/staging/tidspbridge/core/io_sm.c
index c2829aa..42f94e1 100644
--- a/drivers/staging/tidspbridge/core/io_sm.c
+++ b/drivers/staging/tidspbridge/core/io_sm.c
@@ -249,6 +249,7 @@ int bridge_io_create(struct io_mgr **io_man,
 int bridge_io_destroy(struct io_mgr *hio_mgr)
 {
int status = 0;
+
if (hio_mgr) {
/* Free IO DPC object */
tasklet_kill(_mgr->dpc_tasklet);
diff --git a/drivers/staging/tidspbridge/core/tiomap3430.c 
b/drivers/staging/tidspbridge/core/tiomap3430.c
index 8945b4e..bf952ef 100644
--- a/drivers/staging/tidspbridge/core/tiomap3430.c
+++ b/drivers/staging/tidspbridge/core/tiomap3430.c
@@ -1057,6 +1057,7 @@ static int bridge_brd_mem_copy(struct bridge_dev_context 
*dev_ctxt,
u32 total_bytes = ul_num_bytes;
u8 host_buf[BUFFERSIZE];
struct bridge_dev_context *dev_context = dev_ctxt;
+
while (total_bytes > 0 && !status) {
copy_bytes =
total_bytes > BUFFERSIZE ? BUFFERSIZE : total_bytes;
@@ -1094,6 +1095,7 @@ static int bridge_brd_mem_write(struct bridge_dev_context 
*dev_ctxt,
struct bridge_dev_context *dev_context = dev_ctxt;
u32 ul_remain_bytes = 0;
u32 ul_bytes = 0;
+
ul_remain_bytes = ul_num_bytes;
while (ul_remain_bytes > 0 && !status) {
ul_bytes =
diff --git a/drivers/staging/tidspbridge/core/tiomap_io.c 
b/drivers/staging/tidspbridge/core/tiomap_io.c
index f53ed98..2836467 100644
--- a/drivers/staging/tidspbridge/core/tiomap_io.c
+++ b/drivers/staging/tidspbridge/core/tiomap_io.c
@@ -176,6 +176,7 @@ int write_dsp_data(struct bridge_dev_context *dev_context,
struct cfg_hostres *resources = dev_context->resources;
int status = 0;
u32 base1, base2, base3;
+
base1 = OMAP_DSP_MEM1_SIZE;
base2 = OMAP_DSP_MEM2_BASE - OMAP_DSP_MEM1_BASE;
base3 = OMAP_DSP_MEM3_BASE - OMAP_DSP_MEM1_BASE;
@@ -229,6 +230,7 @@ int write_ext_dsp_data(struct bridge_dev_context 
*dev_context,
u32 ul_shm_offset_virt = 0;
struct cfg_hostres *host_res = dev_context->resources;
bool trace_load = false;
+
temp_byte1 = 0x0;
temp_byte2 = 0x0;
 
diff --git a/drivers/staging/tidspbridge/core/wdt.c 
b/drivers/staging/tidspbridge/core/wdt.c
index c7ee467..b19f887 100644
--- a/drivers/staging/tidspbridge/core/wdt.c
+++ b/drivers/staging/tidspbridge/core/wdt.c
@@ -33,6 +33,7 @@ static struct dsp_wdt_setting dsp_wdt;
 void dsp_wdt_dpc(unsigned long data)
 {
struct deh_mgr *deh_mgr;
+
dev_get_deh_mgr(dev_get_first(), _mgr);
if (deh_mgr)
bridge_deh_notify(deh_mgr, DSP_WDTOVERFLOW, 0);
diff --git a/drivers/staging/tidspbridge/dynload/cload.c 
b/drivers/staging/tidspbridge/dynload/cload.c
index 9d54744..83f2106 100644
--- a/drivers/staging/tidspbridge/dynload/cload.c
+++ b/drivers/staging/tidspbridge/dynload/cload.c
@@ -160,6 +160,7 @@ int dynamic_load_module(struct dynamic_loader_stream 
*module,
if (!dl_state.dload_errcount) {
/* fix up entry point address */
unsigned sref = dl_state.dfile_hdr.df_entry_secn - 1;
+
if (sref < dl_state.allocated_secn_count)
dl_state.dfile_hdr.df_entrypt +=
dl_state.ldr_sections[sref].run_addr;
@@ -269,6 +270,7 @@ 

Re: [PATCH] vfio: Fix endianness handling for emulated BARs

[Alexey Kardashevskiy]

On 06/19/2014 11:50 AM, Alexey Kardashevskiy wrote:
> On 06/19/2014 10:50 AM, Alexey Kardashevskiy wrote:
>> On 06/19/2014 04:35 AM, Alex Williamson wrote:
>>> On Wed, 2014-06-18 at 21:36 +1000, Alexey Kardashevskiy wrote:
 VFIO exposes BARs to user space as a byte stream so userspace can
 read it using pread()/pwrite(). Since this is a byte stream, VFIO should
 not do byte swapping and simply return values as it gets them from
 PCI device.

 Instead, the existing code assumes that byte stream in read/write is
 little-endian and it fixes endianness for values which it passes to
 ioreadXX/iowriteXX helpers. This works for little-endian as PCI is
 little endian and le32_to_cpu/... are stubs.
>>>
>>> vfio read32:
>>>
>>> val = cpu_to_le32(ioread32(io + off));
>>>
>>> Where the typical x86 case, ioread32 is:
>>>
>>> #define ioread32(addr)  readl(addr)
>>>
>>> and readl is:
>>>
>>> __le32_to_cpu(__raw_readl(addr));
>>>
>>> So we do canceling byte swaps, which are both nops on x86, and end up
>>> returning device endian, which we assume is little endian.
>>>
>>> vfio write32 is similar:
>>>
>>> iowrite32(le32_to_cpu(val), io + off);
>>>
>>> The implicit cpu_to_le32 of iowrite32() and our explicit swap cancel
>>> out, so input data is device endian, which is assumed little.
>>>
 This also works for big endian but rather by an accident: it reads 4 bytes
 from the stream (@val is big endian), converts to CPU format (which should
 be big endian) as it was little endian (@val becomes actually little
 endian) and calls iowrite32() which does not do swapping on big endian
 system.
>>>
>>> Really?
>>>
>>> In arch/powerpc/kernel/iomap.c iowrite32() is just a wrapper around
>>> writel(), which seems to use the generic implementation, which does
>>> include a cpu_to_le32.
>>
>>
>> Ouch, wrong comment. iowrite32() does swapping. My bad.
>>
>>
>>>
>>> I also see other big endian archs like parisc doing cpu_to_le32 on
>>> iowrite32, so I don't think this statement is true.  I imagine it's
>>> probably working for you because the swap cancel.
>>>
 This removes byte swapping and makes use ioread32be/iowrite32be
 (and 16bit versions) on big-endian systems. The "be" helpers take
 native endian values and do swapping at the moment of writing to a PCI
 register using one of "store byte-reversed" instructions.
>>>
>>> So now you want iowrite32() on little endian and iowrite32be() on big
>>> endian, the former does a cpu_to_le32 (which is a nop on little endian)
>>> and the latter does a cpu_to_be32 (which is a nop on big endian)...
>>> should we just be using __raw_writel() on both?
>>
>>
>> We can do that too. The beauty of iowrite32be on ppc64 is that it does not
>> swap and write separately, it is implemented via the "Store Word
>> Byte-Reverse Indexed X-form" single instruction.
>>
>> And some archs (do not know which ones) may add memory barriers in their
>> implementations of ioread/iowrite. __raw_writel is too raw :)
>>
>>>  There doesn't actually
>>> seem to be any change in behavior here, it just eliminates back-to-back
>>> byte swaps, which are a nop on x86, but not power, right?
>>
>> Exactly. No dependency for QEMU.
> 
> How about that:
> ===
> 
> VFIO exposes BARs to user space as a byte stream so userspace can
> read it using pread()/pwrite(). Since this is a byte stream, VFIO should
> not do byte swapping and simply return values as it gets them from
> PCI device.
> 
> Instead, the existing code assumes that byte stream in read/write is
> little-endian and it fixes endianness for values which it passes to
> ioreadXX/iowriteXX helpers in native format. The IO helpers do swapping
> again. Since both byte swaps are nops on little-endian host, this works.
> 
> This also works for big endian but rather by an accident: it reads 4 bytes
> from the stream (@val is big endian), converts to CPU format (which should
> be big endian) as it was little endian (and @val becomes actually little
> endian) and calls iowrite32() which does swapping on big endian
> system again. So byte swap gets cancelled, __raw_writel() receives
> a native value and then
> *(volatile unsigned int __force *)PCI_FIX_ADDR(addr) = v;
> just does the right thing.

I am wrong here, sorry. This is what happens when you watch soccer between
2am and 4am :)


> 
> This removes byte swaps and makes use of ioread32be/iowrite32be
> (and 16bit versions) which do explicit byte swapping at the moment
> of write to a PCI register. PPC64 uses a special "Store Word
> Byte-Reverse Indexed X-form" instruction which does swap and store.

No swapping is done here if we use ioread32be as it calls in_be32 and that
animal does "lwz" which is simple load from memory.

So @val (16/32 bit variable on stack) will have different values on LE and
BE but since we do not handle it the host and just memcpy it to the buffer,
nothing breaks here.


So it should be like this:
===
VFIO exposes BARs to user 

Re: [ANNOUNCE] 3.12.22-rt33

[Mike Galbraith]

On Wed, 2014-06-18 at 20:12 -0400, Steven Rostedt wrote: 
> Dear RT Folks,
> 
> I'm pleased to announce the 3.12.22-rt33 stable release.


git@marge:~/linux-2.6> git diff v3.12... 
drivers/net/ethernet/dec/tulip/tulip_core.c
diff --git a/drivers/net/ethernet/dec/tulip/tulip_core.c 
b/drivers/net/ethernet/dec/tulip/tulip_core.c
index 4e8cfa2ac803..a6d4653ebbc3 100644
--- a/drivers/net/ethernet/dec/tulip/tulip_core.c
+++ b/drivers/net/ethernet/dec/tulip/tulip_core.c
@@ -1939,7 +1939,9 @@ static void tulip_remove_one(struct pci_dev *pdev)
pci_iounmap(pdev, tp->base_addr);
free_netdev (dev);
pci_release_regions (pdev);
+   pci_disable_device(pdev);
pci_set_drvdata (pdev, NULL);
+   pci_disable_device(pdev);
 
/* pci_power_off (pdev, -1); */
 }

commit 4a77edc195f0b03644e84dda00fcfe9827868e8e
Author: Ingo Molnar 
Date:   Fri Jul 3 08:30:18 2009 -0500

drivers/net: tulip_remove_one needs to call pci_disable_device()

Otherwise the device is not completely shut down.

Signed-off-by: Ingo Molnar 
Signed-off-by: Thomas Gleixner 

diff --git a/drivers/net/ethernet/dec/tulip/tulip_core.c 
b/drivers/net/ethernet/dec/tulip/tulip_core.c
index 4e8cfa2ac803..7565b994ec50 100644
--- a/drivers/net/ethernet/dec/tulip/tulip_core.c
+++ b/drivers/net/ethernet/dec/tulip/tulip_core.c
@@ -1939,6 +1939,7 @@ static void tulip_remove_one(struct pci_dev *pdev)
pci_iounmap(pdev, tp->base_addr);
free_netdev (dev);
pci_release_regions (pdev);
+   pci_disable_device(pdev);
pci_set_drvdata (pdev, NULL);
 
/* pci_power_off (pdev, -1); */


commit 831bb5573dcbeb0da783c82e21084ac191dafc24
Author: Ingo Molnar 
Date:   Fri Feb 14 15:32:20 2014 +0100

drivers/net: tulip_remove_one needs to call pci_disable_device()

commit c321f7d7c87cdc623c87845f6378620573e57512 upstream.

Otherwise the device is not completely shut down.

Signed-off-by: Ingo Molnar 
Signed-off-by: Thomas Gleixner 
Signed-off-by: Sebastian Andrzej Siewior 
Signed-off-by: David S. Miller 
Signed-off-by: Jiri Slaby 

diff --git a/drivers/net/ethernet/dec/tulip/tulip_core.c 
b/drivers/net/ethernet/dec/tulip/tulip_core.c
index 4e8cfa2ac803..779016068a82 100644
--- a/drivers/net/ethernet/dec/tulip/tulip_core.c
+++ b/drivers/net/ethernet/dec/tulip/tulip_core.c
@@ -1940,6 +1940,7 @@ static void tulip_remove_one(struct pci_dev *pdev)
free_netdev (dev);
pci_release_regions (pdev);
pci_set_drvdata (pdev, NULL);
+   pci_disable_device(pdev);
 
/* pci_power_off (pdev, -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: Build error - vmlinux.lds [Re: linux-next: Tree for Jun 18]

[Sachin Kamat]

On Wed, Jun 18, 2014 at 5:50 PM, Russell King - ARM Linux
 wrote:
> On Wed, Jun 18, 2014 at 05:38:14PM +0530, Sachin Kamat wrote:
>> On Wed, Jun 18, 2014 at 5:26 PM, Russell King - ARM Linux
>>  wrote:
>> > On Wed, Jun 18, 2014 at 04:50:43PM +0530, Sachin Kamat wrote:
>> >> Hi,
>> >>
>> >> I observe the following build error while building uImage for ARM.
>> >>
>> >>   Kernel: arch/arm/boot/Image is ready
>> >> make[2]: *** No rule to make target
>> >> `arch/arm/boot/compressed/vmlinux.lds', needed by
>> >> `arch/arm/boot/compressed/vmlinux'.  Stop.
>> >> make[1]: *** [arch/arm/boot/compressed/vmlinux] Error 2
>> >> make: *** [uImage] Error 2
>> >
>> > Works fine here against an empty object tree:
>> >
>> > http://www.arm.linux.org.uk/developer/build/file.php?lid=9591
>> >
>> > Are you building into an already-built object tree or rebuilding an
>> > already built tree?
>>
>> I did a clean build after updating the tree to next-20140618.
>> git status show me the following after doing make clean
>>
>> # On branch master
>> # Changes not staged for commit:
>> #   (use "git add/rm ..." to update what will be committed)
>> #   (use "git checkout -- ..." to discard changes in working directory)
>> #
>> #deleted:arch/arm/boot/compressed/vmlinux.lds.S
>>
>>
>> My tip of kernel points to commit 4ca1fbc122fcb ("Add linux-next specific
>> files for 20140618")
>>
>> >
>> > This is likely caused by make getting confused over the dependencies.
>> > I suggest making clean to recover from this error.
>>
>> I get this error when I do a clean build too.
>
> Hmm.  Please try removing vmlinux.lds.S from extra-y in
> arch/arm/boot/compressed/Makefile and restoring the deleted file.

The above steps work for me. I do not get the aforementioned build
error now.

Thanks.

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

Re: [bisected] pre-3.16 regression on open() scalability

[Andi Kleen]

On Wed, Jun 18, 2014 at 07:13:37PM -0700, Paul E. McKenney wrote:
> On Wed, Jun 18, 2014 at 06:42:00PM -0700, Andi Kleen wrote:
> > 
> > I still think it's totally the wrong direction to pollute so 
> > many fast paths with this obscure debugging check workaround
> > unconditionally.
> 
> OOM prevention should count for something, I would hope.

OOM in what scenario? This is getting bizarre.

If something keeps looping forever in the kernel creating 
RCU callbacks without any real quiescent states it's simply broken.

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

Re: [PATCH 2/2] extcon: gpio: Add dt support for the driver.

[George Cherian]

On 6/17/2014 9:27 PM, Mark Rutland wrote:

On Tue, Jun 17, 2014 at 04:58:20AM +0100, George Cherian wrote:

Add device tree support to extcon-gpio driver.
Add devicetree binding documentation

Signed-off-by: George Cherian 
---
  .../devicetree/bindings/extcon/extcon-gpio.txt | 34 ++
  drivers/extcon/extcon-gpio.c   | 29 ++
  2 files changed, 63 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/extcon/extcon-gpio.txt

diff --git a/Documentation/devicetree/bindings/extcon/extcon-gpio.txt 
b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
new file mode 100644
index 000..80b791b
--- /dev/null
+++ b/Documentation/devicetree/bindings/extcon/extcon-gpio.txt
@@ -0,0 +1,34 @@
+GPIO based EXTCON
+
+EXTCON GPIO
+---
+
+Required Properties:
+ - compatible: should be:
+   * "ti,extcon-gpio"
+ - gpios: specifies the gpio pin used.
+ - debounce: Debounce time for GPIO IRQ in ms
+ - irq-flags: IRQ flag to be used ( eg: IRQ_TYPE_EDGE_FALLING)

This looks distinctly odd. Why do you need this here?
The driver takes this as part of platform data. It never continues 
operation if

an invalid irq-flag is supplied. Also these can be used for different SoC's
whose GPIO's might support IRQ_TYPE_EDGE_FALLING/RISING.
Now since this is based on gpio we cant up front give a seperate
"interrupts = " property, since we dont know the gpio-pin irq number.

Chanwoo any comments?



+Optional Properties:
+ - gpio-active-low: Property describing whether gpio active state is 1 or 0
+   If defined , low state of gpio means active.

Surely this is defined in the gpio flags?


Yes, I will make necessary changes.



+ - check-on-resume: Property describing whether to check the gpio state
+   while resuming from SLEEP.

Does this need to be in DT? Surely we could jsut always check this?

okay. For my use-case I dont need this.
Chanwoo, any comments?

+ - state-on: print_state is overriden with state_on string if provided.
+If NULL, default method of extcon class is used.
+ - state_off: print_state is overriden with state_off string  if provided.
+ If NUll, default method of extcon class is used.

This means nothing from a HW perspective. This describes linux internal
details.

You mean to say this should not be part of dt?


[...]


+   of_property_read_u32(np, "debounce", (u32 *)>debounce);
+   of_property_read_u32(np, "irq-flags", (u32 *)>irq_flags);

If you need theses casts, the code is broken.

I dont need this, will remove in v2.


These functions can only read into a u32. If you pass a smaller type
you'll trash aribtrary memory locations, and if you pass a larger type
this is broken for BE.

true.

Mark.



--
-George

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

Re: [PATCH v2 2/2] arm: dts: add support for AM437x StarterKit

[Nishanth Menon]

On 06/18/2014 10:05 PM, Felipe Balbi wrote:
> Hi,
> 
> On Wed, Jun 18, 2014 at 09:26:01PM -0500, Nishanth Menon wrote:
>> On 06/18/2014 06:19 PM, Felipe Balbi wrote:
>> [...]
>>> Add support for TI's AM437x StarterKit Evaluation
>>> Module.
>>
>> is there a link for this platform?
>
> internal only

 but will eventually be sold externally? I assume this is not an TI
>>>
>>> probably, but there's nothing public yet.
>>>
 internal only board.
>>>
>>> correct assumption for all I know.
>>
>> Yikes.. ok.. I'd let Tony et.al make the call on this, I guess.
> 
> would we really block a DTS just because there's no public wiki page
> available (yet) ?
> 
> Sounds a bit extreme to me.

If this is an TI internal board without anyone outside that a few
select developers being able to get and work on it... I am a bit
skeptical on upstream kernel support and burden for forseeable future
in ensuring it is tested and continually maintained. if it an
one-off.. maybe fork might be good enough.. upstream not too attractive.

I mean, if it is targeted to be sold eventually, I have no objections
or blocks - just make it clear in commit message. I can imagine folks
wondering what the heck this is and googling without results(just like
I did).

[...]

>>> +   cd-gpios = < 6 GPIO_ACTIVE_HIGH>;
>>> +};
>>> +
>>> +_phy1 {
>>> +   status = "okay";
>>> +};
>>> +
>>> + {
>>> +   dr_mode = "peripheral";
>>> +   status = "okay";
>>> +};
>>> +
>>> +_phy2 {
>>> +   status = "okay";
>>> +};
>>> +
>>> + {
>>> +   dr_mode = "host";
>>> +   status = "okay";
>>> +};
>> none of the above need pinctrl? no regulator supplies?
>
> pins in default states, drivers don't use regulators.

 USB works without a supply? even a fixed voltage supply? that is
 weird.
>>>
>>> take a look at the minicom output I posted if you don't believe. Well,
>>> to be exact, tps63010 [1] is the one which generates the regulated V5_0D
>>> which is used as VBUS_USB. The enable pin in that device is tied to the
>>> 3v3 rail (dcdc4 regulator in the PMIC as most everything else) but
>>> there's no way (otherwise) to control that thing. There's no control
>>> bus, no way to write a driver.
>>>
>>> Since the board will anyways turn off if you disable the 3v3 rail, it's
>>> pretty much pointless to figure out a hack just to add this to DTS.
>>>
>>> [1] http://www.ti.com/product/TPS63010
>>
>> I am sure to trust you on the test log :) ->  but then from dts description
>> perspective, it is good if we describe the supplies, even as a always on
>> fixed-regulator. We had instances like 2430SDP ethernet where... umm... we
>> originally missed describing ethernet supply and boom, one fine morning, no
>> more nfs filesystem - I mean, it is a one off scenario there, but describing
>> regulators helps us atleast understand the power tree of the board a little
>> better.
>>
>> Again, no strong opinions on my side, it is a good thing to do is all
>> I feel about it.
> 
> you mean something like:
> 
>   V5_0D: fixedregulator@0 {
>   compatible = "regulator-fixed";
>   regulator-name = "V5_0D";
>   regulator-min-microvolt = <500>;
>   regulator-max-microvolt = <500>;
>   regulator-boot-on;
>   regulator-always-on;
>   vin-supply = <>;
>   };
> 
>   VBUS_USB: fixedregulator@1 {
>   compatible = "regulator-fixed";
>   regulator-name = "VBUS_USB";
>   regulator-min-microvolt = <500>;
>   regulator-max-microvolt = <500>;
>   regulator-boot-on;
>   regulator-always-on;
>   vin-supply = <_0D>;
>   };
> 
> I can add that, but note that it's *solely* to make sysfs look nice. And
> if that's the case, most likely *every* DTS file in tree today as
> incomplete. OTOH, I really consider this to be hugely unnecessary
> because of the fact that board will turn off if 3v3 (dcdc4) is disabled.
> 


Yes - something along those lines - Again, no strong opinions on my
side for these - just that it is a good thing to model in and may help
drivers where can use the awareness.

Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] arm: dts: add support for AM437x StarterKit

[Felipe Balbi]

Hi,

On Wed, Jun 18, 2014 at 09:26:01PM -0500, Nishanth Menon wrote:
> On 06/18/2014 06:19 PM, Felipe Balbi wrote:
> [...]
> >Add support for TI's AM437x StarterKit Evaluation
> >Module.
> 
> is there a link for this platform?
> >>>
> >>>internal only
> >>
> >>but will eventually be sold externally? I assume this is not an TI
> >
> >probably, but there's nothing public yet.
> >
> >>internal only board.
> >
> >correct assumption for all I know.
> 
> Yikes.. ok.. I'd let Tony et.al make the call on this, I guess.

would we really block a DTS just because there's no public wiki page
available (yet) ?

Sounds a bit extreme to me.

> >+edt-ft5306@38 {
> >+status = "okay";
> >+compatible = "edt,edt-ft5306", "edt,edt-ft5x06";
> >+pinctrl-names = "default";
> >+pinctrl-0 = <_ft5306_ts_pins>;
> >+reg = <0x38>;
> >+interrupt-parent = <>;
> >+interrupts = <31 0>;
> >+
> >+wake-gpios = < 28 GPIO_ACTIVE_HIGH>;
> 
> why wake-gpios? we should be using pinctrl with interrupt-extended to
> do wakeup sequence, no?
> >>>
> >>>sure, can you patch the edt driver ? I'll fix the DTS after that gets
> >>>merged
> >>
> >>If you really want to go down that road, so you could probably help
> >>review the pinctrl patches I posted to enable pinctrl wakeup[1]?
> >>
> >>Come on, as of today, there is no ability to suspend AM437x without
> >>doing [1], let alone talk about wakeup gpio vs interrupt-extended. and
> >>do we really want to wakeup from suspend when touch screen is touched?
> >>
> >>Do you expect wake-gpio to work even after doing interrupt based
> >>solution? I am no edt driver expert... maybe you can help me here.
> >
> >you missed the point entirely. This pin is not used for the touchscreen
> >to wake SoC up, it's the other way around, see how the pin is an
> >*output*. Pull it low and the touchscreen won't generate IRQs, won't
> >respond to i2c accesses, etc. Pull it high, and the thing wakes up.
> 
> Aaah.. My apologies.. I was confused. Thanks for clarifying.

np

> [...]
> >+cd-gpios = < 6 GPIO_ACTIVE_HIGH>;
> >+};
> >+
> >+_phy1 {
> >+status = "okay";
> >+};
> >+
> >+ {
> >+dr_mode = "peripheral";
> >+status = "okay";
> >+};
> >+
> >+_phy2 {
> >+status = "okay";
> >+};
> >+
> >+ {
> >+dr_mode = "host";
> >+status = "okay";
> >+};
> none of the above need pinctrl? no regulator supplies?
> >>>
> >>>pins in default states, drivers don't use regulators.
> >>
> >>USB works without a supply? even a fixed voltage supply? that is
> >>weird.
> >
> >take a look at the minicom output I posted if you don't believe. Well,
> >to be exact, tps63010 [1] is the one which generates the regulated V5_0D
> >which is used as VBUS_USB. The enable pin in that device is tied to the
> >3v3 rail (dcdc4 regulator in the PMIC as most everything else) but
> >there's no way (otherwise) to control that thing. There's no control
> >bus, no way to write a driver.
> >
> >Since the board will anyways turn off if you disable the 3v3 rail, it's
> >pretty much pointless to figure out a hack just to add this to DTS.
> >
> >[1] http://www.ti.com/product/TPS63010
> 
> I am sure to trust you on the test log :) ->  but then from dts description
> perspective, it is good if we describe the supplies, even as a always on
> fixed-regulator. We had instances like 2430SDP ethernet where... umm... we
> originally missed describing ethernet supply and boom, one fine morning, no
> more nfs filesystem - I mean, it is a one off scenario there, but describing
> regulators helps us atleast understand the power tree of the board a little
> better.
> 
> Again, no strong opinions on my side, it is a good thing to do is all
> I feel about it.

you mean something like:

V5_0D: fixedregulator@0 {
compatible = "regulator-fixed";
regulator-name = "V5_0D";
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
regulator-boot-on;
regulator-always-on;
vin-supply = <>;
};

VBUS_USB: fixedregulator@1 {
compatible = "regulator-fixed";
regulator-name = "VBUS_USB";
regulator-min-microvolt = <500>;
regulator-max-microvolt = <500>;
regulator-boot-on;
regulator-always-on;
vin-supply = <_0D>;
};

I can add that, but note that it's *solely* to make sysfs look nice. And
if that's the case, most likely *every* DTS file in tree today as
incomplete. OTOH, I really consider this to be hugely unnecessary
because of the fact that board will turn off if 3v3 (dcdc4) is disabled.

-- 

Re: [PATCH v2 6/6] percpu-refcount: implement percpu_ref_reinit() and percpu_ref_is_zero()

[Lai Jiangshan]

On 06/19/2014 10:20 AM, Tejun Heo wrote:
> Now that explicit invocation of percpu_ref_exit() is necessary to free
> the percpu counter, we can implement percpu_ref_reinit() which
> reinitializes a released percpu_ref.  This can be used implement
> scalable gating switch which can be drained and then re-opened without
> worrying about memory allocation failures.
> 
> percpu_ref_is_zero() is added to be used in a sanity check in
> percpu_ref_exit().  As this function will be useful for other purposes
> too, make it a public interface.
> 
> v2: Use smp_read_barrier_depends() instead of smp_load_acquire().  We
> only need data dep barrier and smp_load_acquire() is stronger and
> heavier on some archs.  Spotted by Lai Jiangshan.
> 
> Signed-off-by: Tejun Heo 
> Cc: Kent Overstreet 
> Cc: Christoph Lameter 
> Cc: Lai Jiangshan 
> ---
>  include/linux/percpu-refcount.h |   19 +++
>  lib/percpu-refcount.c   |   35 +++
>  2 files changed, 54 insertions(+)
> 
> --- a/include/linux/percpu-refcount.h
> +++ b/include/linux/percpu-refcount.h
> @@ -67,6 +67,7 @@ struct percpu_ref {
>  
>  int __must_check percpu_ref_init(struct percpu_ref *ref,
>percpu_ref_func_t *release);
> +void percpu_ref_reinit(struct percpu_ref *ref);
>  void percpu_ref_exit(struct percpu_ref *ref);
>  void percpu_ref_kill_and_confirm(struct percpu_ref *ref,
>percpu_ref_func_t *confirm_kill);
> @@ -99,6 +100,9 @@ static inline bool __pcpu_ref_alive(stru
>  {
>   unsigned long pcpu_ptr = ACCESS_ONCE(ref->pcpu_count_ptr);
>  
> + /* paired with smp_store_release() in percpu_ref_reinit() */
> + smp_read_barrier_depends();
> +
>   if (unlikely(pcpu_ptr & PCPU_REF_DEAD))
>   return false;
>  
> @@ -206,4 +210,19 @@ static inline void percpu_ref_put(struct
>   rcu_read_unlock_sched();
>  }
>  
> +/**
> + * percpu_ref_is_zero - test whether a percpu refcount reached zero
> + * @ref: percpu_ref to test
> + *
> + * Returns %true if @ref reached zero.
> + */
> +static inline bool percpu_ref_is_zero(struct percpu_ref *ref)
> +{
> + unsigned __percpu *pcpu_count;
> +
> + if (__pcpu_ref_alive(ref, _count))
> + return false;
> + return !atomic_read(>count);
> +}
> +
>  #endif
> --- a/lib/percpu-refcount.c
> +++ b/lib/percpu-refcount.c
> @@ -61,6 +61,41 @@ int percpu_ref_init(struct percpu_ref *r
>  EXPORT_SYMBOL_GPL(percpu_ref_init);
>  
>  /**
> + * percpu_ref_reinit - re-initialize a percpu refcount
> + * @ref: perpcu_ref to re-initialize
> + *
> + * Re-initialize @ref so that it's in the same state as when it finished
> + * percpu_ref_init().  @ref must have been initialized successfully, killed
> + * and reached 0 but not exited.
> + *
> + * Note that percpu_ref_tryget[_live]() are safe to perform on @ref while
> + * this function is in progress.
> + */
> +void percpu_ref_reinit(struct percpu_ref *ref)
> +{
> + unsigned __percpu *pcpu_count = pcpu_count_ptr(ref);
> + int cpu;
> +
> + BUG_ON(!pcpu_count);
> + WARN_ON(!percpu_ref_is_zero(ref));
> +
> + atomic_set(>count, 1 + PCPU_COUNT_BIAS);
> +
> + /*
> +  * Restore per-cpu operation.  smp_store_release() is paired with
> +  * smp_load_acquire() in __pcpu_ref_alive() and guarantees that the

s/smp_load_acquire()/smp_read_barrier_depends()/

s/smp_store_release()/smp_mb()/  if you accept my next comment.

> +  * zeroing is visible to all percpu accesses which can see the
> +  * following PCPU_REF_DEAD clearing.
> +  */
> + for_each_possible_cpu(cpu)
> + *per_cpu_ptr(pcpu_count, cpu) = 0;
> +
> + smp_store_release(>pcpu_count_ptr,
> +   ref->pcpu_count_ptr & ~PCPU_REF_DEAD);

I think it would be better if smp_mb() is used.

it is documented that smp_read_barrier_depends() and smp_mb() are paired.
Not smp_read_barrier_depends() and smp_store_release().

> +}
> +EXPORT_SYMBOL_GPL(percpu_ref_reinit);
> +
> +/**
>   * percpu_ref_exit - undo percpu_ref_init()
>   * @ref: percpu_ref to exit
>   *
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> .
> 

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

Re: [PATCHv7 2/5] mailbox: Introduce framework for mailbox

[Jassi Brar]

On 18 June 2014 22:33, Kevin Hilman  wrote:
> Jassi Brar  writes:
>
>> On 18 June 2014 05:57, Kevin Hilman  wrote:
>>> Jassi Brar  writes:
>>>
 Introduce common framework for client/protocol drivers and
 controller drivers of Inter-Processor-Communication (IPC).

 Client driver developers should have a look at
  include/linux/mailbox_client.h to understand the part of
 the API exposed to client drivers.
 Similarly controller driver developers should have a look
 at include/linux/mailbox_controller.h

 Signed-off-by: Jassi Brar 
>>>
>>> This series is shaping up nicely.  The one thing I think it would
>>> benefit from, being a new common framework is something under
>>> Documentation giving a brief overview, but more importantly some
>>> example code snippets of a mailbox client using the API, and maybe an
>>> example usage of the controller API as well.
>>>
>>> Not only will that guide developers who want to use/implement this API
>>> on their platforms, it will also aid reviewers.
>>>
>> I have been trying to get it upstream for quite some time now because
>> my platform depends upon it. I am planning to submit my platform
>> support which should have a client and controller side of the mailbox
>> API.
>
> Having a reference implementation is great, but I don't think that
> removes the need for a bit of Documentation when introducing a new
> framework.
>
> It's pretty common to see new IPC mechanisms posted and being able to
> point somone to this framework and something under Documentation/* would
> be a great help in getting more users of the framework.
>
Of course. I didn't mean I won't add Documentation.

>> Though I am told the API (until v4 at least) supported usecases for 5
>> different platforms.
>
> That's great.
>
> I sure would like to see some more Reviewed-by tags from those folks to
> confirm that those starting to use it think it's on the right track.
>
The upstreaming attempts have been going on for months now, and via
non-public interactions with developers I understand it last worked
before the revision mandating DT support and ipc->mailbox symbol
renaming. So basic working should still remain the same.
   Suman(TI), Loic(ST), Girish(Samsung), Ashwin (PCC+ACPI) guys,
any word for v7?

LFTan(Intel) and Craig(Broadcom) seem unresponsive now, unfortunately :(

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

Re: [bisected] pre-3.16 regression on open() scalability

[Mike Galbraith]

On Wed, 2014-06-18 at 19:13 -0700, Paul E. McKenney wrote: 
> On Wed, Jun 18, 2014 at 06:42:00PM -0700, Andi Kleen wrote:
> > 
> > I still think it's totally the wrong direction to pollute so 
> > many fast paths with this obscure debugging check workaround
> > unconditionally.
> 
> OOM prevention should count for something, I would hope.
> 
> > cond_resched() is in EVERY sleeping lock and in EVERY memory allocation!
> > And these are really critical paths for many workloads.
> > 
> > If you really wanted to do this I think you would first need
> > to define a cond_resched_i_am_not_fast() or somesuch.
> > 
> > Or put it all behind some debugging ifdef.
> 
> My first thought was to put it behind CONFIG_NO_HZ_FULL, but everyone
> seems to be enabling that one.

Not everybody, SUSE doesn't even have it enabled in factory.

-Mike

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

Re: [PATCH] staging: rtl8192e: check return value of dev_skb_alloc

[Greg KH]

On Wed, Jun 18, 2014 at 10:24:41PM -0400, Nicholas Krause wrote:
> Checks if dev_skb_alloc returns Null in function, fw_download_code.
> If the return value of dev_skb_alloc is NULL return false and exit
> this function.
> Signed-off-by: Nicholas Krause 
> ---
>  drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c 
> b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
> index 1a95d1f..38ae236 100644
> --- a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
> +++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
> @@ -62,6 +62,8 @@ static bool fw_download_code(struct net_device *dev, u8 
> *code_virtual_address,
>  
>   skb  = dev_alloc_skb(frag_length + 4);
>   memcpy((unsigned char *)(skb->cb), , sizeof(dev));
> + if (!skb)
> + return !rt_status;
>   tcb_desc = (struct cb_desc *)(skb->cb + MAX_DEV_ADDR_SIZE);
>   tcb_desc->queue_index = TXCMD_QUEUE;
>   tcb_desc->bCmdOrInit = DESC_PACKET_TYPE_INIT;

As writing emails to you seems like dumping stuff into a vacuum, I'm
going to just delete this message and start ignoring your mail like you
seem to be ignoring mine...

Best of luck,

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

Re: [bisected] pre-3.16 regression on open() scalability

[Paul E. McKenney]

On Wed, Jun 18, 2014 at 07:13:37PM -0700, Paul E. McKenney wrote:
> On Wed, Jun 18, 2014 at 06:42:00PM -0700, Andi Kleen wrote:
> > 
> > I still think it's totally the wrong direction to pollute so 
> > many fast paths with this obscure debugging check workaround
> > unconditionally.
> 
> OOM prevention should count for something, I would hope.
> 
> > cond_resched() is in EVERY sleeping lock and in EVERY memory allocation!
> > And these are really critical paths for many workloads.
> > 
> > If you really wanted to do this I think you would first need
> > to define a cond_resched_i_am_not_fast() or somesuch.
> > 
> > Or put it all behind some debugging ifdef.
> 
> My first thought was to put it behind CONFIG_NO_HZ_FULL, but everyone
> seems to be enabling that one.
> 
> As mentioned earlier, I could potentially push the check behind
> the need-resched check, which would get it off of the common case
> of the code paths you call out above.

Of course, it would also be good to measure this and see how much it
really hurts.

Thanx, Paul

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

Re: [PATCH RFC - TAKE TWO - 00/12] New version of the BFQ I/O Scheduler

[Jens Axboe]

On 2014-06-18 18:46, Tejun Heo wrote:

Hello,

On Tue, Jun 17, 2014 at 05:55:57PM +0200, Paolo Valente wrote:

In general, with both a smooth but messy and a sharp but clean
transformation, there seems to be the following common problems:

1) The main benefits highlighted by Jens, i.e., being able to move
back and forth and easily understand what works and what does not,
seem to be lost, because, with both solutions, intermediate versions
would likely have a worse performance than the current version of
cfq.


So, the perfectly smooth and performant transformation is possible,
it'd be great, but I don't really think that'd be the case.  My
opinion is that if the infrastructure pieces can be mostly maintained
while making logical gradual steps it should be fine.  ie. pick
whatever strategy which seems executable, chop down the pieces which
get in the way (ie. tear down all the cfq heuristics if you have to),
transform the base and then build things on top again.  Ensuring that
each step is logical and keeps working should give us enough safety
net, IMO.

Jens, what do you think?


I was thinking the same - strip CFQ back down, getting rid of the 
heuristics, then go forward to BFQ. That should be feasible. You need to 
find the common core first.



2) bfq, on one side, does not export some of the sysfs parameters of
cfq, such as slice_sync, and, on the other side, uses other common
parameters in a different way. For example, bfq turns I/O priorities
into throughput shares in a different way than cfq does. As a
consequence, existing configurations may break or behave in
unexpected ways.


This is why I hate exposing internal knobs without layering proper
semantic interpretation on top.  It ends up creating unnecessary
lock-in effect too often just to serve some esoteric cases which
aren't all that useful.  For knobs which don't make any sense for the
new scheduler, the appropriate thing to do would be just making them
noop and generate a warning message when it's written to.

As for behavior change for existing users, any change to scheduler
does that.  I don't think it's practical to avoid any changes for that
reason.  I think there already is a pretty solid platform to base
things on and the way forward is making the changes and iterating as
testing goes on and issues get reported.


Completely agree, don't worry about that. It's not like we advertise 
hard guarantees on the priorities right now, for instance, so as long as 
the end result isn't orders of magnitude different for the 
classes/levels, then it'll likely be good enough.


Ditto on the sysfs files, as some of those are likely fairly widely 
used. But if we warn and do nothing, then that'll allow us to sort out 
popular uses of it before we (later on) remove the files.


--
Jens Axboe

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

Re: [RFC][PATCH] ftrace: Use schedule_on_each_cpu() as a heavy synchronize_sched()

[Paul E. McKenney]

On Wed, Jun 18, 2014 at 09:56:26PM -0400, Steven Rostedt wrote:
> 
> Another blast from the past (from the book of cleaning out inbox)
> 
> On Wed, 29 May 2013 09:52:49 +0200
> Peter Zijlstra  wrote:
> 
> > On Tue, May 28, 2013 at 08:01:16PM -0400, Steven Rostedt wrote:
> > > The function tracer uses preempt_disable/enable_notrace() for
> > > synchronization between reading registered ftrace_ops and unregistering
> > > them.
> > > 
> > > Most of the ftrace_ops are global permanent structures that do not
> > > require this synchronization. That is, ops may be added and removed from
> > > the hlist but are never freed, and wont hurt if a synchronization is
> > > missed.
> > > 
> > > But this is not true for dynamically created ftrace_ops or control_ops,
> > > which are used by the perf function tracing.
> > > 
> > > The problem here is that the function tracer can be used to trace
> > > kernel/user context switches as well as going to and from idle.
> > > Basically, it can be used to trace blind spots of the RCU subsystem.
> > > This means that even though preempt_disable() is done, a
> > > synchronize_sched() will ignore CPUs that haven't made it out of user
> > > space or idle. These can include functions that are being traced just
> > > before entering or exiting the kernel sections.
> > 
> > Just to be clear, its the idle part that's a problem, right? Being stuck
> > in userspace isn't a problem since if that CPU is in userspace its
> > certainly not got a reference to whatever list entry we're removing.
> > 
> > Now when the CPU really is idle, its obviously not using tracing either;
> > so only the gray area where RCU thinks we're idle but we're not actually
> > idle is a problem?
> > 
> > Is there something a little smarter we can do? Could we use
> > on_each_cpu_cond() with a function that checks if the CPU really is
> > fully idle?
> > 
> > > To implement the RCU synchronization, instead of using
> > > synchronize_sched() the use of schedule_on_each_cpu() is performed. This
> > > means that when a dynamically allocated ftrace_ops, or a control ops is
> > > being unregistered, all CPUs must be touched and execute a ftrace_sync()
> > > stub function via the work queues. This will rip CPUs out from idle or
> > > in dynamic tick mode. This only happens when a user disables perf
> > > function tracing or other dynamically allocated function tracers, but it
> > > allows us to continue to debug RCU and context tracking with function
> > > tracing.
> > 
> > I don't suppose there's anything perf can do to about this right? Since
> > its all on user demand we're kinda stuck with dynamic memory.
> 
> If Paul finished his "synchronize_all_tasks_scheduled()" then we could
> use that instead. Where "synchornize_all_tasks_scheduled()" would
> return after all tasks have either scheduled, in userspace, or idle
> (that is, not on the run queue). And scheduled means a non preempted
> schedule, where the task itself actually called schedule.
> 
> Paul, how you doing on that? You said you could have something by 3.17.
> That's coming up quick :-)

I am still expecting to, depite my misadventures with performance
regressions.

Thanx, Paul

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

Re: [PATCH 6/6] percpu-refcount: implement percpu_ref_reinit() and percpu_ref_is_zero()

[Paul E. McKenney]

On Wed, Jun 18, 2014 at 10:07:27PM -0400, Tejun Heo wrote:
> On Thu, Jun 19, 2014 at 09:58:16AM +0800, Lai Jiangshan wrote:
> > On 06/18/2014 11:32 PM, Tejun Heo wrote:
> > > On Wed, Jun 18, 2014 at 11:37:35AM +0800, Lai Jiangshan wrote:
> > >>> @@ -97,7 +98,10 @@ static inline void percpu_ref_kill(struct percpu_ref 
> > >>> *ref)
> > >>>  static inline bool __pcpu_ref_alive(struct percpu_ref *ref,
> > >>> unsigned __percpu **pcpu_countp)
> > >>>  {
> > >>> -   unsigned long pcpu_ptr = ACCESS_ONCE(ref->pcpu_count_ptr);
> > >>> +   unsigned long pcpu_ptr;
> > >>> +
> > >>> +   /* paired with smp_store_release() in percpu_ref_reinit() */
> > >>> +   pcpu_ptr = smp_load_acquire(>pcpu_count_ptr);
> > >>
> > >>
> > >> Does "smp_load_acquire()" hurts the performance of percpu_ref_get/put()
> > >> in non-x86 system?
> > > 
> > > It's equivalent to data dependency barrier.  The only arch which needs
> > > something more than barrier() is alpha.  It isn't an issue.
> > 
> > But I searched from the source, smp_load_acquire() is just barrier() in
> > x86, arm64, ia64, s390, sparc, but it includes memory barrier 
> > instruction in other archs.
> 
> Hmmm, right, it's a stronger guarantee than the data dependency
> barrier.  This should probably use smp_wmb() and
> smp_read_barrier_depends().  That's all it needs anyway.

Yep, smp_load_acquire() orders its load against later loads and stores,
so it really does need a memory barrier on weakly ordered systems.

This is the "publish" operation for dynamically allocated per-CPU
references?  If so, agreed, you should be able to rely on dependency
ordering.  Make sure to comment the smp_read_barrier_depends().  ;-)

Thanx, Paul

> Thanks.
> 
> -- 
> tejun
> 

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

Re: [PATCH 1/1] media: dib9000: avoid out of bound access

[Kees Cook]

On Wed, Jun 18, 2014 at 6:41 PM, Heinrich Schuchardt  wrote:
> On 19.06.2014 01:50, Kees Cook wrote:
>>
>> On Wed, Jun 18, 2014 at 3:02 PM, Heinrich Schuchardt 
>> wrote:
>>>
>>> The current test to avoid out of bound access to mb[] is insufficient.
>>> For len = 19 non-existent mb[10] will be accessed.
>>>
>>> A check in the for loop is insufficient to avoid out of bound access in
>>> dib9000_mbx_send_attr.
>>>
>>> Signed-off-by: Heinrich Schuchardt 
>>> ---
>>>   drivers/media/dvb-frontends/dib9000.c | 5 -
>>>   1 file changed, 4 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/drivers/media/dvb-frontends/dib9000.c
>>> b/drivers/media/dvb-frontends/dib9000.c
>>> index e540cfb..6a71917 100644
>>> --- a/drivers/media/dvb-frontends/dib9000.c
>>> +++ b/drivers/media/dvb-frontends/dib9000.c
>>> @@ -1040,10 +1040,13 @@ static int dib9000_risc_apb_access_write(struct
>>> dib9000_state *state, u32 addres
>>>  if (address >= 1024 || !state->platform.risc.fw_is_running)
>>>  return -EINVAL;
>>>
>>> +   if (len > 18)
>>> +   return -EINVAL;
>>> +
>>>  /* dprintk( "APB access thru wr fw %d %x", address, attribute);
>>> */
>>>
>>>  mb[0] = (unsigned short)address;
>>> -   for (i = 0; i < len && i < 20; i += 2)
>>> +   for (i = 0; i < len; i += 2)
>>>  mb[1 + (i / 2)] = (b[i] << 8 | b[i + 1]);
>>
>>
>> Good catch on the mb[] access! However, I think there is still more to
>> fix since b[i + 1] can read past the end of b: Say b is defined as "u8
>> b[3]". Passing len 3 means the second loop, with i==2 will access b[2]
>> and b[3], the latter is out of range.
>
>
> b[] and len are provided by the caller of dib9000_risc_apb_access_write.
> dib9000_risc_apb_access_write cannot verify if the length of b[] matches len
> at all.
>
> Currently dib9000_risc_apb_access_write cannot handle odd values of len.
> This holds even true if b[] has been padded with zero to an even length: For
> odd values of len the last byte is not passed to dib9000_mbx_send_attr.
>
> What is left unclear is how odd values of len should be handled correctly:
>
> Should the caller provide a b[] padded with 0 to the next even number of
> bytes,
> or should dib9000_risc_apb_access_write take care not to read more then len
> bytes,
> or should odd values of len cause an error EINVAL.
>
> From what I read in the coding one source of the value of len is
> tuner_attach(), which is called from outside the dib9000 driver.

How about:

for (i = 0; i < len; i += 2) {
u16 val = b[i] << 8;
if (i + 1 < len)
 val |= b[i + 1];
mb[1 + (i / 2)] = val;

That's defensive, and would have the same effect of callers doing the padding.

-Kees

>
> Heinrich
>
>
>>
>> -Kees
>>
>>>
>>>  dib9000_mbx_send_attr(state, OUT_MSG_BRIDGE_APB_W, mb, 1 + len /
>>> 2, attribute);
>>> --
>>> 2.0.0
>>>
>>
>>
>>
>



-- 
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] arm: dts: add support for AM437x StarterKit

[Nishanth Menon]

On 06/18/2014 06:19 PM, Felipe Balbi wrote:
[...]

Add support for TI's AM437x StarterKit Evaluation
Module.


is there a link for this platform?


internal only


but will eventually be sold externally? I assume this is not an TI


probably, but there's nothing public yet.


internal only board.


correct assumption for all I know.


Yikes.. ok.. I'd let Tony et.al make the call on this, I guess.

[...]

+   edt-ft5306@38 {
+   status = "okay";
+   compatible = "edt,edt-ft5306", "edt,edt-ft5x06";
+   pinctrl-names = "default";
+   pinctrl-0 = <_ft5306_ts_pins>;
+   reg = <0x38>;
+   interrupt-parent = <>;
+   interrupts = <31 0>;
+
+   wake-gpios = < 28 GPIO_ACTIVE_HIGH>;


why wake-gpios? we should be using pinctrl with interrupt-extended to
do wakeup sequence, no?


sure, can you patch the edt driver ? I'll fix the DTS after that gets
merged


If you really want to go down that road, so you could probably help
review the pinctrl patches I posted to enable pinctrl wakeup[1]?

Come on, as of today, there is no ability to suspend AM437x without
doing [1], let alone talk about wakeup gpio vs interrupt-extended. and
do we really want to wakeup from suspend when touch screen is touched?

Do you expect wake-gpio to work even after doing interrupt based
solution? I am no edt driver expert... maybe you can help me here.


you missed the point entirely. This pin is not used for the touchscreen
to wake SoC up, it's the other way around, see how the pin is an
*output*. Pull it low and the touchscreen won't generate IRQs, won't
respond to i2c accesses, etc. Pull it high, and the thing wakes up.


Aaah.. My apologies.. I was confused. Thanks for clarifying.

[...]

+   cd-gpios = < 6 GPIO_ACTIVE_HIGH>;
+};
+
+_phy1 {
+   status = "okay";
+};
+
+ {
+   dr_mode = "peripheral";
+   status = "okay";
+};
+
+_phy2 {
+   status = "okay";
+};
+
+ {
+   dr_mode = "host";
+   status = "okay";
+};

none of the above need pinctrl? no regulator supplies?


pins in default states, drivers don't use regulators.


USB works without a supply? even a fixed voltage supply? that is
weird.


take a look at the minicom output I posted if you don't believe. Well,
to be exact, tps63010 [1] is the one which generates the regulated V5_0D
which is used as VBUS_USB. The enable pin in that device is tied to the
3v3 rail (dcdc4 regulator in the PMIC as most everything else) but
there's no way (otherwise) to control that thing. There's no control
bus, no way to write a driver.

Since the board will anyways turn off if you disable the 3v3 rail, it's
pretty much pointless to figure out a hack just to add this to DTS.

[1] http://www.ti.com/product/TPS63010


I am sure to trust you on the test log :) ->  but then from dts 
description perspective, it is good if we describe the supplies, even as 
a always on fixed-regulator. We had instances like 2430SDP ethernet 
where... umm... we originally missed describing ethernet supply and 
boom, one fine morning, no more nfs filesystem - I mean, it is a one off 
scenario there, but describing regulators helps us atleast understand 
the power tree of the board a little better.


Again, no strong opinions on my side, it is a good thing to do is all I 
feel about it.


--
Regards,
Nishanth Menon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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-ima-user] [PATCH] audit: fix dangling keywords in integrity ima message output

[Richard Guy Briggs]

On 14/06/17, Mimi Zohar wrote:
> On Mon, 2014-06-16 at 15:52 -0400, Richard Guy Briggs wrote:
> > Replace spaces in op keyword labels in log output since userspace audit 
> > tools
> > can't parse orphaned keywords.
> 
> The patch didn't apply cleanly to linux-integrity/#next.  Please take a
> look at it (linux-integrity/#next-fixes).

Looks like just the change from "const char *op" to "static const char
op[]" in the context.  Looks fine to me.

> thanks,

Thanks Mimi.

> Mimi 
> 
> > Reported-by: Steve Grubb 
> > Signed-off-by: Richard Guy Briggs 
> > ---
> >  security/integrity/ima/ima_appraise.c |2 +-
> >  security/integrity/ima/ima_policy.c   |6 +++---
> >  2 files changed, 4 insertions(+), 4 deletions(-)
> > 
> > diff --git a/security/integrity/ima/ima_appraise.c 
> > b/security/integrity/ima/ima_appraise.c
> > index 734e946..61c95af 100644
> > --- a/security/integrity/ima/ima_appraise.c
> > +++ b/security/integrity/ima/ima_appraise.c
> > @@ -214,7 +214,7 @@ int ima_appraise_measurement(int func, struct 
> > integrity_iint_cache *iint,
> > hash_start = 1;
> > case IMA_XATTR_DIGEST:
> > if (iint->flags & IMA_DIGSIG_REQUIRED) {
> > -   cause = "IMA signature required";
> > +   cause = "IMA-signature-required";
> > status = INTEGRITY_FAIL;
> > break;
> > }
> > diff --git a/security/integrity/ima/ima_policy.c 
> > b/security/integrity/ima/ima_policy.c
> > index a9c3d3c..dbdc528 100644
> > --- a/security/integrity/ima/ima_policy.c
> > +++ b/security/integrity/ima/ima_policy.c
> > @@ -330,7 +330,7 @@ void __init ima_init_policy(void)
> >  void ima_update_policy(void)
> >  {
> > const char *op = "policy_update";
> > -   const char *cause = "already exists";
> > +   const char *cause = "already-exists";
> > int result = 1;
> > int audit_info = 0;
> > 
> > @@ -654,7 +654,7 @@ ssize_t ima_parse_add_rule(char *rule)
> > /* Prevent installed policy from changing */
> > if (ima_rules != _default_rules) {
> > integrity_audit_msg(AUDIT_INTEGRITY_STATUS, NULL,
> > -   NULL, op, "already exists",
> > +   NULL, op, "already-exists",
> > -EACCES, audit_info);
> > return -EACCES;
> > }
> > @@ -680,7 +680,7 @@ ssize_t ima_parse_add_rule(char *rule)
> > if (result) {
> > kfree(entry);
> > integrity_audit_msg(AUDIT_INTEGRITY_STATUS, NULL,
> > -   NULL, op, "invalid policy", result,
> > +   NULL, op, "invalid-policy", result,
> > audit_info);
> > return result;
> > }

- RGB

--
Richard Guy Briggs 
Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red 
Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] staging: rtl8192e: check return value of dev_skb_alloc

[Nicholas Krause]

Checks if dev_skb_alloc returns Null in function, fw_download_code.
If the return value of dev_skb_alloc is NULL return false and exit
this function.
Signed-off-by: Nicholas Krause 
---
 drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c 
b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
index 1a95d1f..38ae236 100644
--- a/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
+++ b/drivers/staging/rtl8192e/rtl8192e/r8192E_firmware.c
@@ -62,6 +62,8 @@ static bool fw_download_code(struct net_device *dev, u8 
*code_virtual_address,
 
skb  = dev_alloc_skb(frag_length + 4);
memcpy((unsigned char *)(skb->cb), , sizeof(dev));
+   if (!skb)
+   return !rt_status;
tcb_desc = (struct cb_desc *)(skb->cb + MAX_DEV_ADDR_SIZE);
tcb_desc->queue_index = TXCMD_QUEUE;
tcb_desc->bCmdOrInit = DESC_PACKET_TYPE_INIT;
-- 
1.9.1

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

[PATCH v2 6/6] percpu-refcount: implement percpu_ref_reinit() and percpu_ref_is_zero()

[Tejun Heo]

Now that explicit invocation of percpu_ref_exit() is necessary to free
the percpu counter, we can implement percpu_ref_reinit() which
reinitializes a released percpu_ref.  This can be used implement
scalable gating switch which can be drained and then re-opened without
worrying about memory allocation failures.

percpu_ref_is_zero() is added to be used in a sanity check in
percpu_ref_exit().  As this function will be useful for other purposes
too, make it a public interface.

v2: Use smp_read_barrier_depends() instead of smp_load_acquire().  We
only need data dep barrier and smp_load_acquire() is stronger and
heavier on some archs.  Spotted by Lai Jiangshan.

Signed-off-by: Tejun Heo 
Cc: Kent Overstreet 
Cc: Christoph Lameter 
Cc: Lai Jiangshan 
---
 include/linux/percpu-refcount.h |   19 +++
 lib/percpu-refcount.c   |   35 +++
 2 files changed, 54 insertions(+)

--- a/include/linux/percpu-refcount.h
+++ b/include/linux/percpu-refcount.h
@@ -67,6 +67,7 @@ struct percpu_ref {
 
 int __must_check percpu_ref_init(struct percpu_ref *ref,
 percpu_ref_func_t *release);
+void percpu_ref_reinit(struct percpu_ref *ref);
 void percpu_ref_exit(struct percpu_ref *ref);
 void percpu_ref_kill_and_confirm(struct percpu_ref *ref,
 percpu_ref_func_t *confirm_kill);
@@ -99,6 +100,9 @@ static inline bool __pcpu_ref_alive(stru
 {
unsigned long pcpu_ptr = ACCESS_ONCE(ref->pcpu_count_ptr);
 
+   /* paired with smp_store_release() in percpu_ref_reinit() */
+   smp_read_barrier_depends();
+
if (unlikely(pcpu_ptr & PCPU_REF_DEAD))
return false;
 
@@ -206,4 +210,19 @@ static inline void percpu_ref_put(struct
rcu_read_unlock_sched();
 }
 
+/**
+ * percpu_ref_is_zero - test whether a percpu refcount reached zero
+ * @ref: percpu_ref to test
+ *
+ * Returns %true if @ref reached zero.
+ */
+static inline bool percpu_ref_is_zero(struct percpu_ref *ref)
+{
+   unsigned __percpu *pcpu_count;
+
+   if (__pcpu_ref_alive(ref, _count))
+   return false;
+   return !atomic_read(>count);
+}
+
 #endif
--- a/lib/percpu-refcount.c
+++ b/lib/percpu-refcount.c
@@ -61,6 +61,41 @@ int percpu_ref_init(struct percpu_ref *r
 EXPORT_SYMBOL_GPL(percpu_ref_init);
 
 /**
+ * percpu_ref_reinit - re-initialize a percpu refcount
+ * @ref: perpcu_ref to re-initialize
+ *
+ * Re-initialize @ref so that it's in the same state as when it finished
+ * percpu_ref_init().  @ref must have been initialized successfully, killed
+ * and reached 0 but not exited.
+ *
+ * Note that percpu_ref_tryget[_live]() are safe to perform on @ref while
+ * this function is in progress.
+ */
+void percpu_ref_reinit(struct percpu_ref *ref)
+{
+   unsigned __percpu *pcpu_count = pcpu_count_ptr(ref);
+   int cpu;
+
+   BUG_ON(!pcpu_count);
+   WARN_ON(!percpu_ref_is_zero(ref));
+
+   atomic_set(>count, 1 + PCPU_COUNT_BIAS);
+
+   /*
+* Restore per-cpu operation.  smp_store_release() is paired with
+* smp_load_acquire() in __pcpu_ref_alive() and guarantees that the
+* zeroing is visible to all percpu accesses which can see the
+* following PCPU_REF_DEAD clearing.
+*/
+   for_each_possible_cpu(cpu)
+   *per_cpu_ptr(pcpu_count, cpu) = 0;
+
+   smp_store_release(>pcpu_count_ptr,
+ ref->pcpu_count_ptr & ~PCPU_REF_DEAD);
+}
+EXPORT_SYMBOL_GPL(percpu_ref_reinit);
+
+/**
  * percpu_ref_exit - undo percpu_ref_init()
  * @ref: percpu_ref to exit
  *
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] x86: tsc: get rid of custom DIV_ROUND

[David Rientjes]

On Thu, 19 Jun 2014, Michal Nazarewicz wrote:

> When invoced for positive values, DIV_ROUND macro defined in
> arch/x86/kernel/tsc.c behaves exactly like DIV_ROUND_CLOSEST from
> include/linux/kernel.h file, so remove the custom macro in favour
> of the shared one.
> 
> Signed-off-by: Michal Nazarewicz 

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

Re: [bisected] pre-3.16 regression on open() scalability

[Paul E. McKenney]

On Wed, Jun 18, 2014 at 06:42:00PM -0700, Andi Kleen wrote:
> 
> I still think it's totally the wrong direction to pollute so 
> many fast paths with this obscure debugging check workaround
> unconditionally.

OOM prevention should count for something, I would hope.

> cond_resched() is in EVERY sleeping lock and in EVERY memory allocation!
> And these are really critical paths for many workloads.
> 
> If you really wanted to do this I think you would first need
> to define a cond_resched_i_am_not_fast() or somesuch.
> 
> Or put it all behind some debugging ifdef.

My first thought was to put it behind CONFIG_NO_HZ_FULL, but everyone
seems to be enabling that one.

As mentioned earlier, I could potentially push the check behind
the need-resched check, which would get it off of the common case
of the code paths you call out above.

Thanx, Paul

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

Re: [PATCH -tip v2 0/3] ftrace, kprobes: Introduce IPMODIFY flag for ftrace_ops to detect conflicts

[Josh Poimboeuf]

On Tue, Jun 17, 2014 at 11:04:36AM +, Masami Hiramatsu wrote:
> Hi,
> 
> Here is the version 2 of the series of patches which introduces
> IPMODIFY flag for ftrace_ops to detect conflicts of ftrace users
> who can modify regs->ip in their handler.
> In this version, I fixed some bugs in previous version and
> added a patch which made kprobe itself free from IPMODIFY
> except for jprobe.

Hi Masami,

This seems better, but I still saw a few issues.  I'm not sure if the
issues are specific to stap or kprobes.  For the following issues I used
this command to set a kprobe:

  stap -v -e 'probe kernel.function("meminfo_proc_show") 
{printf("meminfo_proc_show called\n");}'

With patches 1-2, when I used stap to kprobe the function after it was
already kpatched, stap didn't return an error and instead acted like it
succeeded (though the probe didn't work):

  $ sudo stap -v -e 'probe kernel.function("meminfo_proc_show") 
{printf("meminfo_proc_show called\n");}'
  Pass 1: parsed user script and 112 library script(s) using 
221516virt/41612res/6028shr/36228data kb, in 130usr/0sys/132real ms.
  Pass 2: analyzed script: 1 probe(s), 0 function(s), 0 embed(s), 0 global(s) 
using 255840virt/77132res/7132shr/70552data kb, in 510usr/20sys/577real ms.
  Pass 3: translated to C into 
"/tmp/stap3Qunba/stap_2690192fea570fb7bba78c7ed7fa1e0d_898_src.c" using 
255840virt/77392res/7392shr/70552data kb, in 10usr/0sys/4real ms.
  Pass 4: compiled C into "stap_2690192fea570fb7bba78c7ed7fa1e0d_898.ko" in 
5020usr/640sys/7105real ms.
  Pass 5: starting run.
  (no error)

With all 3 patches, I expected kprobes and kpatch to be able to ftrace
the same function.  But when I tried to kpatch the function after it was
kprobed, I got the following oops in stap:

  [  455.842797] BUG: unable to handle kernel NULL pointer dereference at 
0020
  [  455.843388] IP: [] _stp_module_notifier+0x1e/0x320 
[stap_2690192fea570fb7bba78c7ed7fa1e_20189]
  [  455.844011] PGD 33f898067 PUD 422083067 PMD 0 
  [  455.844638] Oops:  [#1] SMP 
  [  455.845255] Modules linked in: kpatch(OE+) 
stap_2690192fea570fb7bba78c7ed7fa1e_20189(OE) rfcomm ipt_MASQUERADE fuse ccm 
xt_CHECKSUM tun ip6t_rpfilter ip6t_REJECT xt_conntrack ebtable_nat 
ebtable_broute bridge stp llc ebtable_filter ebtables ip6table_nat 
nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_mangle ip6table_security 
ip6table_raw ip6table_filter ip6_tables iptable_nat nf_conntrack_ipv4 
nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_security 
iptable_raw bnep arc4 iwldvm mac80211 iTCO_wdt snd_hda_codec_hdmi 
iTCO_vendor_support x86_pkg_temp_thermal snd_hda_codec_realtek coretemp iwlwifi 
snd_hda_codec_generic kvm_intel snd_hda_intel kvm uvcvideo snd_hda_controller 
cfg80211 snd_hda_codec btusb videobuf2_vmalloc bluetooth videobuf2_memops 
snd_hwdep snd_seq nfsd videobuf2_core
  [  455.848272]  v4l2_common videodev snd_seq_device e1000e microcode snd_pcm 
sdhci_pci media joydev sdhci serio_raw i2c_i801 pcspkr mmc_core thinkpad_acpi 
mei_me snd_timer auth_rpcgss mei snd lpc_ich ptp mfd_core shpchp nfs_acl lockd 
pps_core wmi tpm_tis soundcore tpm rfkill sunrpc dm_crypt i915 i2c_algo_bit 
drm_kms_helper drm crct10dif_pclmul crc32_pclmul crc32c_intel 
ghash_clmulni_intel i2c_core video
  [  455.850887] CPU: 3 PID: 19857 Comm: insmod Tainted: GW  OE 
3.16.0-rc1+ #2
  [  455.851768] Hardware name: LENOVO 2356BH8/2356BH8, BIOS G7ET63WW (2.05 ) 
11/12/2012
  [  455.852638] task: 880095d65460 ti: 88039d1d4000 task.ti: 
88039d1d4000
  [  455.853456] RIP: 0010:[]  [] 
_stp_module_notifier+0x1e/0x320 [stap_2690192fea570fb7bba78c7ed7fa1e_20189]
  [  455.854335] RSP: 0018:88039d1d7ce0  EFLAGS: 00010246
  [  455.855212] RAX: a0837f50 RBX:  RCX: 

  [  455.856109] RDX: a08400e0 RSI: 0001 RDI: 
a0837f50
  [  455.856986] RBP: 88039d1d7d00 R08:  R09: 

  [  455.857880] R10: 0001 R11: c9001aed2d8f R12: 
81c593e0
  [  455.858761] R13: 0001 R14: a08400e0 R15: 

  [  455.859640] FS:  7feac5f10740() GS:88043e2c() 
knlGS:
  [  455.860523] CS:  0010 DS:  ES:  CR0: 80050033
  [  455.861403] CR2: 0020 CR3: 0004224e7000 CR4: 
001407e0
  [  455.862309] Stack:
  [  455.863236]  fffd 81c593e0 0001 
a08400e0
  [  455.864163]  88039d1d7d38 810b45bc 81c557c0 

  [  455.865103]  0001 a08400e0  
88039d1d7d78
  [  455.866067] Call Trace:
  [  455.867100]  [] notifier_call_chain+0x4c/0x70
  [  455.868202]  [] __blocking_notifier_call_chain+0x4d/0x70
  [  455.869155]  [] blocking_notifier_call_chain+0x16/0x20
  [  455.870111]  [] load_module+0x1aac/0x25f0
  [  455.871067]  [] ? kernel_read+0x50/0x80
  [  455.872022]  [] 

Re: [PATCH 6/6] percpu-refcount: implement percpu_ref_reinit() and percpu_ref_is_zero()

[Tejun Heo]

On Thu, Jun 19, 2014 at 09:58:16AM +0800, Lai Jiangshan wrote:
> On 06/18/2014 11:32 PM, Tejun Heo wrote:
> > On Wed, Jun 18, 2014 at 11:37:35AM +0800, Lai Jiangshan wrote:
> >>> @@ -97,7 +98,10 @@ static inline void percpu_ref_kill(struct percpu_ref 
> >>> *ref)
> >>>  static inline bool __pcpu_ref_alive(struct percpu_ref *ref,
> >>>   unsigned __percpu **pcpu_countp)
> >>>  {
> >>> - unsigned long pcpu_ptr = ACCESS_ONCE(ref->pcpu_count_ptr);
> >>> + unsigned long pcpu_ptr;
> >>> +
> >>> + /* paired with smp_store_release() in percpu_ref_reinit() */
> >>> + pcpu_ptr = smp_load_acquire(>pcpu_count_ptr);
> >>
> >>
> >> Does "smp_load_acquire()" hurts the performance of percpu_ref_get/put()
> >> in non-x86 system?
> > 
> > It's equivalent to data dependency barrier.  The only arch which needs
> > something more than barrier() is alpha.  It isn't an issue.
> > 
> 
> But I searched from the source, smp_load_acquire() is just barrier() in
> x86, arm64, ia64, s390, sparc, but it includes memory barrier 
> instruction in other archs.

Hmmm, right, it's a stronger guarantee than the data dependency
barrier.  This should probably use smp_wmb() and
smp_read_barrier_depends().  That's all it needs anyway.

Thanks.

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

Re: XFS WARN_ON in xfs_vm_writepage

[Dave Chinner]

On Fri, Jun 13, 2014 at 10:19:25AM -0400, Dave Jones wrote:
> On Fri, Jun 13, 2014 at 04:26:45PM +1000, Dave Chinner wrote:
> 
> > >  970 if (WARN_ON_ONCE((current->flags & (PF_MEMALLOC|PF_KSWAPD)) 
> > > ==
> > >  971 PF_MEMALLOC))
> >
> > What were you running at the time? The XFS warning is there to
> > indicate that memory reclaim is doing something it shouldn't (i.e.
> > dirty page writeback from direct reclaim), so this is one for the mm
> > folk to work out...
> 
> Trinity had driven the machine deeply into swap, and the oom killer was
> kicking in pretty often. Then this happened.

Yup, sounds like a problem somewhere in mm/vmscan.c

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.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] x86: tsc: get rid of custom DIV_ROUND

[Michal Nazarewicz]

When invoced for positive values, DIV_ROUND macro defined in
arch/x86/kernel/tsc.c behaves exactly like DIV_ROUND_CLOSEST from
include/linux/kernel.h file, so remove the custom macro in favour
of the shared one.

Signed-off-by: Michal Nazarewicz 
---
 arch/x86/kernel/tsc.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

 No changes after compilation:

 $ ll tsc.o.*
 -rw--- 1 mpn eng 46497 Jun 19 03:54 tsc.o.after
 -rw--- 1 mpn eng 46497 Jun 19 03:55 tsc.o.before
 $ objdump -d tsc.o.before >tsc.s.before
 $ objdump -d tsc.o.after >tsc.s.after
 $ diff -u tsc.s.before tsc.s.after
 --- tsc.s.before   2014-06-19 03:56:54.880545041 +0200
 +++ tsc.s.after2014-06-19 03:56:54.884545079 +0200
 @@ -1,5 +1,5 @@
  
 -tsc.o.before: file format elf64-x86-64
 +tsc.o.after: file format elf64-x86-64
  
  
  Disassembly of section .text:
 $

diff --git a/arch/x86/kernel/tsc.c b/arch/x86/kernel/tsc.c
index 57e5ce1..02f21c0 100644
--- a/arch/x86/kernel/tsc.c
+++ b/arch/x86/kernel/tsc.c
@@ -234,9 +234,6 @@ static inline unsigned long long cycles_2_ns(unsigned long 
long cyc)
return ns;
 }
 
-/* XXX surely we already have this someplace in the kernel?! */
-#define DIV_ROUND(n, d) (((n) + ((d) / 2)) / (d))
-
 static void set_cyc2ns_scale(unsigned long cpu_khz, int cpu)
 {
unsigned long long tsc_now, ns_now;
@@ -259,7 +256,8 @@ static void set_cyc2ns_scale(unsigned long cpu_khz, int cpu)
 * time function is continuous; see the comment near struct
 * cyc2ns_data.
 */
-   data->cyc2ns_mul = DIV_ROUND(NSEC_PER_MSEC << CYC2NS_SCALE_FACTOR, 
cpu_khz);
+   data->cyc2ns_mul = DIV_ROUND_CLOSEST(
+   NSEC_PER_MSEC << CYC2NS_SCALE_FACTOR, cpu_khz);
data->cyc2ns_shift = CYC2NS_SCALE_FACTOR;
data->cyc2ns_offset = ns_now -
mul_u64_u32_shr(tsc_now, data->cyc2ns_mul, CYC2NS_SCALE_FACTOR);
-- 
2.0.0.526.g5318336

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 6/6] percpu-refcount: implement percpu_ref_reinit() and percpu_ref_is_zero()

[Lai Jiangshan]

On 06/18/2014 11:32 PM, Tejun Heo wrote:
> On Wed, Jun 18, 2014 at 11:37:35AM +0800, Lai Jiangshan wrote:
>>> @@ -97,7 +98,10 @@ static inline void percpu_ref_kill(struct percpu_ref 
>>> *ref)
>>>  static inline bool __pcpu_ref_alive(struct percpu_ref *ref,
>>> unsigned __percpu **pcpu_countp)
>>>  {
>>> -   unsigned long pcpu_ptr = ACCESS_ONCE(ref->pcpu_count_ptr);
>>> +   unsigned long pcpu_ptr;
>>> +
>>> +   /* paired with smp_store_release() in percpu_ref_reinit() */
>>> +   pcpu_ptr = smp_load_acquire(>pcpu_count_ptr);
>>
>>
>> Does "smp_load_acquire()" hurts the performance of percpu_ref_get/put()
>> in non-x86 system?
> 
> It's equivalent to data dependency barrier.  The only arch which needs
> something more than barrier() is alpha.  It isn't an issue.
> 

But I searched from the source, smp_load_acquire() is just barrier() in
x86, arm64, ia64, s390, sparc, but it includes memory barrier 
instruction in other archs.

CC Paul. If smp_load_acquire() is sufficient lightweight, I would update
the SRCU.

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

Re: [RFC][PATCH] ftrace: Use schedule_on_each_cpu() as a heavy synchronize_sched()

[Steven Rostedt]

Another blast from the past (from the book of cleaning out inbox)

On Wed, 29 May 2013 09:52:49 +0200
Peter Zijlstra  wrote:

> On Tue, May 28, 2013 at 08:01:16PM -0400, Steven Rostedt wrote:
> > The function tracer uses preempt_disable/enable_notrace() for
> > synchronization between reading registered ftrace_ops and unregistering
> > them.
> > 
> > Most of the ftrace_ops are global permanent structures that do not
> > require this synchronization. That is, ops may be added and removed from
> > the hlist but are never freed, and wont hurt if a synchronization is
> > missed.
> > 
> > But this is not true for dynamically created ftrace_ops or control_ops,
> > which are used by the perf function tracing.
> > 
> > The problem here is that the function tracer can be used to trace
> > kernel/user context switches as well as going to and from idle.
> > Basically, it can be used to trace blind spots of the RCU subsystem.
> > This means that even though preempt_disable() is done, a
> > synchronize_sched() will ignore CPUs that haven't made it out of user
> > space or idle. These can include functions that are being traced just
> > before entering or exiting the kernel sections.
> 
> Just to be clear, its the idle part that's a problem, right? Being stuck
> in userspace isn't a problem since if that CPU is in userspace its
> certainly not got a reference to whatever list entry we're removing.
> 
> Now when the CPU really is idle, its obviously not using tracing either;
> so only the gray area where RCU thinks we're idle but we're not actually
> idle is a problem?
> 
> Is there something a little smarter we can do? Could we use
> on_each_cpu_cond() with a function that checks if the CPU really is
> fully idle?
> 
> > To implement the RCU synchronization, instead of using
> > synchronize_sched() the use of schedule_on_each_cpu() is performed. This
> > means that when a dynamically allocated ftrace_ops, or a control ops is
> > being unregistered, all CPUs must be touched and execute a ftrace_sync()
> > stub function via the work queues. This will rip CPUs out from idle or
> > in dynamic tick mode. This only happens when a user disables perf
> > function tracing or other dynamically allocated function tracers, but it
> > allows us to continue to debug RCU and context tracking with function
> > tracing.
> 
> I don't suppose there's anything perf can do to about this right? Since
> its all on user demand we're kinda stuck with dynamic memory.

If Paul finished his "synchronize_all_tasks_scheduled()" then we could
use that instead. Where "synchornize_all_tasks_scheduled()" would
return after all tasks have either scheduled, in userspace, or idle
(that is, not on the run queue). And scheduled means a non preempted
schedule, where the task itself actually called schedule.

Paul, how you doing on that? You said you could have something by 3.17.
That's coming up quick :-)

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

Re: [PATCH 2/2] mmc: rtsx: add support for async request

[micky]

On 06/18/2014 07:03 PM, Ulf Hansson wrote:

On 18 June 2014 12:08, micky  wrote:

On 06/18/2014 03:39 PM, Ulf Hansson wrote:

On 18 June 2014 03:17, micky  wrote:

On 06/17/2014 03:45 PM, Ulf Hansson wrote:

On 17 June 2014 03:04, micky  wrote:

On 06/16/2014 08:40 PM, Ulf Hansson wrote:

On 16 June 2014 11:09, micky  wrote:

On 06/16/2014 04:42 PM, Ulf Hansson wrote:

@@ -36,7 +37,10 @@ struct realtek_pci_sdmmc {

struct rtsx_pcr *pcr;
struct mmc_host *mmc;
struct mmc_request  *mrq;
+   struct workqueue_struct *workq;
+#define SDMMC_WORKQ_NAME   "rtsx_pci_sdmmc_workq"

+   struct work_struct  work;

I am trying to understand why you need a work/workqueue to implement
this feature. Is that really the case?

Could you elaborate on the reasons?

Hi Uffe,

we need return as fast as possible in mmc_host_ops
request(ops->request)
callback,
so the mmc core can continue handle next request.
when next request everything is ready, it will wait previous done(if
not
done),
then call ops->request().

we can't use atomic context, because we use mutex_lock() to protect

ops->request should never executed in atomic context. Is that your
concern?

Yes.

Okay. Unless I missed your point, I don't think you need the
work/workqueue.

any other method?


Because, ops->request isn't ever executed in atomic context. That's
due to the mmc core, which handles the async mechanism, are waiting
for a completion variable in process context, before it invokes the
ops->request() callback.

That completion variable will be kicked, from your host driver, when
you invoke mmc_request_done(), .

Sorry, I don't understand here, how kicked?

mmc_request_done()
  ->mrq->done()
  ->mmc_wait_done()
  ->complete(>completion);


I think the flow is:
- not wait for first req
- init mrq->done
- ops->request() --- A.rtsx: start queue
work.
- continue fetch next req
- prepare next req ok,
- wait previous done.--- B.(mmc_request_done() may be
called
at any time from A to B)
- init mrq->done
- ops->request() --- C.rtsx: start queue
next work.
...
and seems no problem.

Right, I don't think there are any _problem_ by using the workqueue as
you have implemented, but I am questioning if it's correct. Simply
because I don't think there are any reasons to why you need a
workqueue, it doesn't solve any problem for you - it just adds
overhead.

Hi Uffe,

we have two driver under mfd, the rtsx-mmc and rtsx-ms,
we use mutex lock(pcr_mutex) to protect resource,
when we handle mmc request, we need hold the mutex until we finish the
request,
so it will not interruptted by rtsx-ms request.

Ahh, I see. Now, _that_ explains why you want the workqueue. :-) Thanks!


If we not use workq, once the request hold the mutex, we have to wait until
the request finish,
then release mutex, so the mmc core is blocking at here.
To implement nonblocking request, we have to use workq.

One minor suggestion below, please consider this as an optimization
which goes outside the context of this patch.

There are cases when I think you should be able to skip the overhead
from scheduling the work from ->request(). Those cases can be
described as when the mutex are available which can be tested by using
mutex_trylock().

Thanks for your suggestion.

we need schedule the work every time mmc core call ops->request(),
if we want to handle request, we need hold mutex and do the work.
so mutex_trylock() will not help decrease overhead.
if we not schedule the work, the ops->request will do nothing.

Best Regards.
micky

Kind regards
Uffe
.



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

Re: [v3.10.y][v3.11.y][v3.12.y][v3.13.y][v3.14.y][PATCH 1/1][V2] ALSA: usb-audio: Prevent printk ratelimiting from spamming kernel log while DEBUG not defined

[Ben Hutchings]

On Wed, 2014-06-18 at 14:32 -0400, Joseph Salisbury wrote:
> From: Sander Eikelenboom 
> 
> BugLink: http://bugs.launchpad.net/bugs/1319457
> 
> This (widely used) construction:
> 
> if(printk_ratelimit())
>   dev_dbg()
> 
> Causes the ratelimiting to spam the kernel log with the "callbacks suppressed"
> message below, even while the dev_dbg it is supposed to rate limit wouldn't
> print anything because DEBUG is not defined for this device.
> 
> [  533.803964] retire_playback_urb: 852 callbacks suppressed
> [  538.807930] retire_playback_urb: 852 callbacks suppressed
> [  543.811897] retire_playback_urb: 852 callbacks suppressed
> [  548.815745] retire_playback_urb: 852 callbacks suppressed
> [  553.819826] retire_playback_urb: 852 callbacks suppressed
> 
> So use dev_dbg_ratelimited() instead of this construction.
> 
> Signed-off-by: Sander Eikelenboom 
> Signed-off-by: Takashi Iwai 
> (backported from commit b7a7723513dc89f83d6df13206df55d4dc26e825)
> Signed-off-by: Joseph Salisbury 

It looks like you have combined the commit identified here with the
preceding:

commit a5065eb6da55b226661456e6a7435f605df98111
Author: Tim Gardner 
Date:   Wed Apr 9 11:30:44 2014 -0600

ALSA: usb-audio: Suppress repetitive debug messages from 
retire_playback_urb()

They should not be squashed together like this.

Ben.

> ---
>  sound/usb/pcm.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/sound/usb/pcm.c b/sound/usb/pcm.c
> index ca3256d..ede4b92 100644
> --- a/sound/usb/pcm.c
> +++ b/sound/usb/pcm.c
> @@ -1488,7 +1488,8 @@ static void retire_playback_urb(struct 
> snd_usb_substream *subs,
>* on two reads of a counter updated every ms.
>*/
>   if (abs(est_delay - subs->last_delay) * 1000 > runtime->rate * 2)
> - snd_printk(KERN_DEBUG "delay: estimated %d, actual %d\n",
> + dev_dbg_ratelimited(>dev->dev,
> + "delay: estimated %d, actual %d\n",
>   est_delay, subs->last_delay);
>  
>   if (!subs->running) {

-- 
Ben Hutchings
It's easier to fight for one's principles than to live up to them.


signature.asc
Description: This is a digitally signed message part

[PATCH] drivers:video:fbdev atmel_lcdfb.c power GPIO registration bug

[Michael Welling]

A list that was intended for storing power control GPIOs was never
initialized correctly or filled. Without these lines of added code
the kernel hangs when trying to access an uninitialized list when a
power control GPIO is registered with the device tree.

Signed-off-by: Michael Welling 
---
 drivers/video/fbdev/atmel_lcdfb.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/video/fbdev/atmel_lcdfb.c 
b/drivers/video/fbdev/atmel_lcdfb.c
index e683b6e..d36e830 100644
--- a/drivers/video/fbdev/atmel_lcdfb.c
+++ b/drivers/video/fbdev/atmel_lcdfb.c
@@ -1057,6 +1057,7 @@ static int atmel_lcdfb_of_init(struct atmel_lcdfb_info 
*sinfo)
goto put_display_node;
}
 
+   INIT_LIST_HEAD(>pwr_gpios);
ret = -ENOMEM;
for (i = 0; i < of_gpio_named_count(display_np, 
"atmel,power-control-gpio"); i++) {
gpio = of_get_named_gpio_flags(display_np, 
"atmel,power-control-gpio",
@@ -1082,6 +1083,7 @@ static int atmel_lcdfb_of_init(struct atmel_lcdfb_info 
*sinfo)
dev_err(dev, "set direction output gpio %d failed\n", 
gpio);
goto put_display_node;
}
+   list_add(>list, >pwr_gpios);
}
 
if (is_gpio_power)
-- 
1.7.9.5

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

Re: [PATCH] vfio: Fix endianness handling for emulated BARs

[Alexey Kardashevskiy]

On 06/19/2014 10:50 AM, Alexey Kardashevskiy wrote:
> On 06/19/2014 04:35 AM, Alex Williamson wrote:
>> On Wed, 2014-06-18 at 21:36 +1000, Alexey Kardashevskiy wrote:
>>> VFIO exposes BARs to user space as a byte stream so userspace can
>>> read it using pread()/pwrite(). Since this is a byte stream, VFIO should
>>> not do byte swapping and simply return values as it gets them from
>>> PCI device.
>>>
>>> Instead, the existing code assumes that byte stream in read/write is
>>> little-endian and it fixes endianness for values which it passes to
>>> ioreadXX/iowriteXX helpers. This works for little-endian as PCI is
>>> little endian and le32_to_cpu/... are stubs.
>>
>> vfio read32:
>>
>> val = cpu_to_le32(ioread32(io + off));
>>
>> Where the typical x86 case, ioread32 is:
>>
>> #define ioread32(addr)  readl(addr)
>>
>> and readl is:
>>
>> __le32_to_cpu(__raw_readl(addr));
>>
>> So we do canceling byte swaps, which are both nops on x86, and end up
>> returning device endian, which we assume is little endian.
>>
>> vfio write32 is similar:
>>
>> iowrite32(le32_to_cpu(val), io + off);
>>
>> The implicit cpu_to_le32 of iowrite32() and our explicit swap cancel
>> out, so input data is device endian, which is assumed little.
>>
>>> This also works for big endian but rather by an accident: it reads 4 bytes
>>> from the stream (@val is big endian), converts to CPU format (which should
>>> be big endian) as it was little endian (@val becomes actually little
>>> endian) and calls iowrite32() which does not do swapping on big endian
>>> system.
>>
>> Really?
>>
>> In arch/powerpc/kernel/iomap.c iowrite32() is just a wrapper around
>> writel(), which seems to use the generic implementation, which does
>> include a cpu_to_le32.
> 
> 
> Ouch, wrong comment. iowrite32() does swapping. My bad.
> 
> 
>>
>> I also see other big endian archs like parisc doing cpu_to_le32 on
>> iowrite32, so I don't think this statement is true.  I imagine it's
>> probably working for you because the swap cancel.
>>
>>> This removes byte swapping and makes use ioread32be/iowrite32be
>>> (and 16bit versions) on big-endian systems. The "be" helpers take
>>> native endian values and do swapping at the moment of writing to a PCI
>>> register using one of "store byte-reversed" instructions.
>>
>> So now you want iowrite32() on little endian and iowrite32be() on big
>> endian, the former does a cpu_to_le32 (which is a nop on little endian)
>> and the latter does a cpu_to_be32 (which is a nop on big endian)...
>> should we just be using __raw_writel() on both?
> 
> 
> We can do that too. The beauty of iowrite32be on ppc64 is that it does not
> swap and write separately, it is implemented via the "Store Word
> Byte-Reverse Indexed X-form" single instruction.
> 
> And some archs (do not know which ones) may add memory barriers in their
> implementations of ioread/iowrite. __raw_writel is too raw :)
> 
>>  There doesn't actually
>> seem to be any change in behavior here, it just eliminates back-to-back
>> byte swaps, which are a nop on x86, but not power, right?
> 
> Exactly. No dependency for QEMU.

How about that:
===

VFIO exposes BARs to user space as a byte stream so userspace can
read it using pread()/pwrite(). Since this is a byte stream, VFIO should
not do byte swapping and simply return values as it gets them from
PCI device.

Instead, the existing code assumes that byte stream in read/write is
little-endian and it fixes endianness for values which it passes to
ioreadXX/iowriteXX helpers in native format. The IO helpers do swapping
again. Since both byte swaps are nops on little-endian host, this works.

This also works for big endian but rather by an accident: it reads 4 bytes
from the stream (@val is big endian), converts to CPU format (which should
be big endian) as it was little endian (and @val becomes actually little
endian) and calls iowrite32() which does swapping on big endian
system again. So byte swap gets cancelled, __raw_writel() receives
a native value and then
*(volatile unsigned int __force *)PCI_FIX_ADDR(addr) = v;
just does the right thing.

This removes byte swaps and makes use of ioread32be/iowrite32be
(and 16bit versions) which do explicit byte swapping at the moment
of write to a PCI register. PPC64 uses a special "Store Word
Byte-Reverse Indexed X-form" instruction which does swap and store.
===

any better?




>>> Suggested-by: Benjamin Herrenschmidt 
>>> Signed-off-by: Alexey Kardashevskiy 
>>> ---
>>>  drivers/vfio/pci/vfio_pci_rdwr.c | 20 
>>>  1 file changed, 16 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/vfio/pci/vfio_pci_rdwr.c 
>>> b/drivers/vfio/pci/vfio_pci_rdwr.c
>>> index 210db24..f363b5a 100644
>>> --- a/drivers/vfio/pci/vfio_pci_rdwr.c
>>> +++ b/drivers/vfio/pci/vfio_pci_rdwr.c
>>> @@ -21,6 +21,18 @@
>>>  
>>>  #include "vfio_pci_private.h"
>>>  
>>> +#ifdef __BIG_ENDIAN__
>>> +#define ioread16_nativeioread16be
>>> +#define ioread32_native

Re: [PATCH] vfio: Fix endianness handling for emulated BARs

[Alexey Kardashevskiy]

On 06/19/2014 10:50 AM, Alexey Kardashevskiy wrote:
> On 06/19/2014 04:35 AM, Alex Williamson wrote:
>> On Wed, 2014-06-18 at 21:36 +1000, Alexey Kardashevskiy wrote:
>>> VFIO exposes BARs to user space as a byte stream so userspace can
>>> read it using pread()/pwrite(). Since this is a byte stream, VFIO should
>>> not do byte swapping and simply return values as it gets them from
>>> PCI device.
>>>
>>> Instead, the existing code assumes that byte stream in read/write is
>>> little-endian and it fixes endianness for values which it passes to
>>> ioreadXX/iowriteXX helpers. This works for little-endian as PCI is
>>> little endian and le32_to_cpu/... are stubs.
>>
>> vfio read32:
>>
>> val = cpu_to_le32(ioread32(io + off));
>>
>> Where the typical x86 case, ioread32 is:
>>
>> #define ioread32(addr)  readl(addr)
>>
>> and readl is:
>>
>> __le32_to_cpu(__raw_readl(addr));
>>
>> So we do canceling byte swaps, which are both nops on x86, and end up
>> returning device endian, which we assume is little endian.
>>
>> vfio write32 is similar:
>>
>> iowrite32(le32_to_cpu(val), io + off);
>>
>> The implicit cpu_to_le32 of iowrite32() and our explicit swap cancel
>> out, so input data is device endian, which is assumed little.
>>
>>> This also works for big endian but rather by an accident: it reads 4 bytes
>>> from the stream (@val is big endian), converts to CPU format (which should
>>> be big endian) as it was little endian (@val becomes actually little
>>> endian) and calls iowrite32() which does not do swapping on big endian
>>> system.
>>
>> Really?
>>
>> In arch/powerpc/kernel/iomap.c iowrite32() is just a wrapper around
>> writel(), which seems to use the generic implementation, which does
>> include a cpu_to_le32.
> 
> 
> Ouch, wrong comment. iowrite32() does swapping. My bad.
> 
> 
>>
>> I also see other big endian archs like parisc doing cpu_to_le32 on
>> iowrite32, so I don't think this statement is true.  I imagine it's
>> probably working for you because the swap cancel.
>>
>>> This removes byte swapping and makes use ioread32be/iowrite32be
>>> (and 16bit versions) on big-endian systems. The "be" helpers take
>>> native endian values and do swapping at the moment of writing to a PCI
>>> register using one of "store byte-reversed" instructions.
>>
>> So now you want iowrite32() on little endian and iowrite32be() on big
>> endian, the former does a cpu_to_le32 (which is a nop on little endian)
>> and the latter does a cpu_to_be32 (which is a nop on big endian)...
>> should we just be using __raw_writel() on both?
> 
> 
> We can do that too. The beauty of iowrite32be on ppc64 is that it does not
> swap and write separately, it is implemented via the "Store Word
> Byte-Reverse Indexed X-form" single instruction.
> 
> And some archs (do not know which ones) may add memory barriers in their
> implementations of ioread/iowrite. __raw_writel is too raw :)
> 
>>  There doesn't actually
>> seem to be any change in behavior here, it just eliminates back-to-back
>> byte swaps, which are a nop on x86, but not power, right?
> 
> Exactly. No dependency for QEMU.

How about that:
===

VFIO exposes BARs to user space as a byte stream so userspace can
read it using pread()/pwrite(). Since this is a byte stream, VFIO should
not do byte swapping and simply return values as it gets them from
PCI device.

Instead, the existing code assumes that byte stream in read/write is
little-endian and it fixes endianness for values which it passes to
ioreadXX/iowriteXX helpers in native format. The IO helpers do swapping
again. Since both byte swaps are nops on little-endian host, this works.

This also works for big endian but rather by an accident: it reads 4 bytes
from the stream (@val is big endian), converts to CPU format (which should
be big endian) as it was little endian (and @val becomes actually little
endian) and calls iowrite32() which does swapping on big endian
system again. So byte swap gets cancelled, __raw_writel() receives
a native value and then
*(volatile unsigned int __force *)PCI_FIX_ADDR(addr) = v;
just does the right thing.

This removes byte swaps and makes use of ioread32be/iowrite32be
(and 16bit versions) which do explicit byte swapping at the moment
of write to a PCI register. PPC64 uses a special "Store Word
Byte-Reverse Indexed X-form" instruction which does swap and store.
===

any better?




>>> Suggested-by: Benjamin Herrenschmidt 
>>> Signed-off-by: Alexey Kardashevskiy 
>>> ---
>>>  drivers/vfio/pci/vfio_pci_rdwr.c | 20 
>>>  1 file changed, 16 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/drivers/vfio/pci/vfio_pci_rdwr.c 
>>> b/drivers/vfio/pci/vfio_pci_rdwr.c
>>> index 210db24..f363b5a 100644
>>> --- a/drivers/vfio/pci/vfio_pci_rdwr.c
>>> +++ b/drivers/vfio/pci/vfio_pci_rdwr.c
>>> @@ -21,6 +21,18 @@
>>>  
>>>  #include "vfio_pci_private.h"
>>>  
>>> +#ifdef __BIG_ENDIAN__
>>> +#define ioread16_nativeioread16be
>>> +#define ioread32_native

Re: [PATCH RFC - TAKE TWO - 00/12] New version of the BFQ I/O Scheduler

[Tejun Heo]

On Wed, Jun 18, 2014 at 09:46:00PM -0400, Tejun Heo wrote:
...
> So, the perfectly smooth and performant transformation is possible,
 ^
 if
> it'd be great, but I don't really think that'd be the case.  My

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

Re: [PATCH] USB:gadget: Fix a warning while loading g_mass_storage

[Yang,Wei]

On 06/18/2014 07:44 PM, Michal Nazarewicz wrote:

On Wed, Jun 18 2014, Yang,Wei wrote:

On 06/17/2014 10:18 PM, Alan Stern wrote:

That is a strange question to ask.  If you did not know that I approved
the patch, why did you insert my Acked-By:?

I added your Acked-By, as when you reviewed V3, you mentioned that I
*may* add your Acked-by in this patch. If I misunderstood your point, I
am so sorry for that.

Alan's point is that if you have any doubts whether someone approves
your patch you should *not* add their Acked-by.  So adding someone's
Acked-by and then asking if they are fine with the patch is
contradictory -- the former indicates that you believe the person is
fine with the patch, while the latter shows that you aren't.

Alan wrote:


With that change, you may add

Acked-by: Alan Stern 

so after adding “that change” you are in your right to add Alan's
Acked-by, but what that also means is that Alan will be fine with the
patch if you make the requested change, so you don't need to ask for an
opinion again.

PS. Note that “having any doubts” also means that if someone gave you
 their Acked-by, but then you substantially rewrite the patch, you
 probably should consider removing their Acked-by.


Michal, Thank you for your detailed explanation, it is very helpful to me.

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

Re: [Intel-gfx] [PATCH v2] iommu/intel: Exclude devices using RMRRs from IOMMU API domains

[Alex Williamson]

On Wed, 2014-06-18 at 15:48 -0600, Alex Williamson wrote:
> On Tue, 2014-06-17 at 15:44 +0200, Daniel Vetter wrote:
> > On Tue, Jun 17, 2014 at 07:16:22AM -0600, Alex Williamson wrote:
> > > On Tue, 2014-06-17 at 13:41 +0100, David Woodhouse wrote:
> > > > On Tue, 2014-06-17 at 06:22 -0600, Alex Williamson wrote:
> > > > > On Tue, 2014-06-17 at 08:04 +0100, David Woodhouse wrote:
> > > > > > On Mon, 2014-06-16 at 23:35 -0600, Alex Williamson wrote:
> > > > > > > 
> > > > > > > Any idea what an off-the-shelf Asus motherboard would be doing 
> > > > > > > with an
> > > > > > > RMRR on the Intel HD graphics?
> > > > > > > 
> > > > > > > dmar: RMRR base: 0x00bb80 end: 0x00bf9f
> > > > > > > IOMMU: Setting identity map for device :00:02.0 [0xbb80 - 
> > > > > > > 0xbf9f]
> > > > > > 
> > > > > > Hm, we should have thought of that sooner. That's quite normal — 
> > > > > > it's
> > > > > > for the 'stolen' memory used for the framebuffer. And maybe also the
> > > > > > GTT, and shadow GTT and other things; I forget precisely what, and 
> > > > > > it
> > > > > > varies from one setup to another.
> > > > > 
> > > > > Why exactly do these things need to be identity mapped through the
> > > > > IOMMU?  This sounds like something a normal device might do with a
> > > > > coherent mapping.
> > > > 
> > > > The BIOS (EFI or VESA) sets up a framebuffer in stolen main memory. It's
> > > > accessed by DMA, using the physical address. The RMRR exists because we
> > > > need it *not* to suddenly stop working the moment the OS turns on the
> > > > IOMMU.
> > > > 
> > > > The OS graphics driver, if any, is not loaded at this point.
> > > > 
> > > > And even later, the OS graphics driver may choose to make use of the
> > > > 'stolen' memory for various purposes. And since it was already stolen,
> > > > it doesn't go and set up *another* mapping for it; it knows that a
> > > > mapping already exists.
> > > > 
> > > > > > I'd expect fairly much all systems to have an RMRR for the 
> > > > > > integrated
> > > > > > graphics device if they have one, and your patch¹ is going to 
> > > > > > prevent
> > > > > > assignment of those to guests... as you've presumably noticed.
> > > > > > 
> > > > > > I'm not sure if the i915 driver is capable of fully reprogramming 
> > > > > > the
> > > > > > hardware to completely stop using that region, to allow assignment 
> > > > > > to a
> > > > > > guest with a 'pure' memory map and no stolen region. I suppose it 
> > > > > > must,
> > > > > > if assignment to guests was working correctly before?
> > > > > 
> > > > > IGD assignment has never worked with KVM.
> > > > 
> > > > Hm. It works with Xen though, doesn't it?
> > > 
> > > Apparently
> > > 
> > > > Are we content to say that it'll *never* work with KVM, and thus we can
> > > > live with the fact that your patch makes it harder to fix whatever was
> > > > wrong in the first place?
> > > 
> > > Probably not.  However, it seems like you're saying that this RMRR is
> > > used by and visible to OS level drivers, versus backchannel
> > > communication channels, invisible to the OS.  I think the latter is
> > > specifically what we want to prevent by excluding devices with RMRRs.
> > > This is a challenging use case, but it seems to be understood.  If when
> > > IGD is bound to vfio-pci we can be sure that access to the RMRR area
> > > ceases, then we can tear it down and re-establish it from
> > > userspace/QEMU, describe it to the guest in an e820 reserved region, and
> > > never consider hotplug of the device for guests.  If that's the case,
> > > maybe it's another exception, like USB.  I'll need to look through i915
> > > more to find how the region is discovered.  Thanks,
> > 
> > We have a bunch of register in the mmio bar set up by the bios that tells
> > us the address and size of the stolen range we can use. The address we
> > need for programming ptes, the size to know how much there is. We also
> > have an early boot pci quirk in x86 nowadays to make sure the pci layer
> > doesn't put random stuff in that range.
> > 
> > See drivers/gpu/drm/i915/i915_gem_gtt.c (search for stolen size)
> > i915_gem_stolen.c (look at stolen_to_phys) and the early quirks in
> > arch/x86/kernel/early-quirks.c for copies of the same code.
> 
> Ok, here's what I observe on my system for a few settings of iGPU memory
> size in the BIOS.  The device ID for this IGD is 0152, so I'm using the
> gen6_stolen_funcs stolen functions from early quirks for stolen
> base/size.  I also report the ASL Storage base, ie. the opregion since
> that also needs to be punched through if this device were to be
> assigned.
> 
> "1024M"
> [0.628033] IOMMU: Setting identity map for device :00:02.0 
> [0xbf80 - 0xbf9f]
> [0.00] BIOS-e820: [mem 0xbf80-0xbf9f] reserved
> 
> setpci -s 2.0 5c.l
> 7fa1
> setpci -s 2.0 50.l
> 0289
> 
> (289 >> 3) & 1f = 0x11, 17 * 32M = 544M
> 
> stolen memory range: 

Re: [PATCH RFC - TAKE TWO - 00/12] New version of the BFQ I/O Scheduler

[Tejun Heo]

Hello,

On Tue, Jun 17, 2014 at 05:55:57PM +0200, Paolo Valente wrote:
> In general, with both a smooth but messy and a sharp but clean
> transformation, there seems to be the following common problems:
>
> 1) The main benefits highlighted by Jens, i.e., being able to move
> back and forth and easily understand what works and what does not,
> seem to be lost, because, with both solutions, intermediate versions
> would likely have a worse performance than the current version of
> cfq.

So, the perfectly smooth and performant transformation is possible,
it'd be great, but I don't really think that'd be the case.  My
opinion is that if the infrastructure pieces can be mostly maintained
while making logical gradual steps it should be fine.  ie. pick
whatever strategy which seems executable, chop down the pieces which
get in the way (ie. tear down all the cfq heuristics if you have to),
transform the base and then build things on top again.  Ensuring that
each step is logical and keeps working should give us enough safety
net, IMO.

Jens, what do you think?

> 2) bfq, on one side, does not export some of the sysfs parameters of
> cfq, such as slice_sync, and, on the other side, uses other common
> parameters in a different way. For example, bfq turns I/O priorities
> into throughput shares in a different way than cfq does. As a
> consequence, existing configurations may break or behave in
> unexpected ways.

This is why I hate exposing internal knobs without layering proper
semantic interpretation on top.  It ends up creating unnecessary
lock-in effect too often just to serve some esoteric cases which
aren't all that useful.  For knobs which don't make any sense for the
new scheduler, the appropriate thing to do would be just making them
noop and generate a warning message when it's written to.

As for behavior change for existing users, any change to scheduler
does that.  I don't think it's practical to avoid any changes for that
reason.  I think there already is a pretty solid platform to base
things on and the way forward is making the changes and iterating as
testing goes on and issues get reported.

Thanks.

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

[for-next][PATCH 1/3] tracing: Fix syscall_*regfunc() vs copy_process() race

[Steven Rostedt]

From: Oleg Nesterov 

syscall_regfunc() and syscall_unregfunc() should set/clear
TIF_SYSCALL_TRACEPOINT system-wide, but do_each_thread() can race
with copy_process() and miss the new child which was not added to
the process/thread lists yet.

Change copy_process() to update the child's TIF_SYSCALL_TRACEPOINT
under tasklist.

Link: http://lkml.kernel.org/p/20140413185854.gb20...@redhat.com

Cc: sta...@vger.kernel.org # 2.6.33
Fixes: a871bd33a6c0 "tracing: Add syscall tracepoints"
Acked-by: Frederic Weisbecker 
Signed-off-by: Oleg Nesterov 
Signed-off-by: Steven Rostedt 
---
 include/trace/syscall.h | 15 +++
 kernel/fork.c   |  2 ++
 2 files changed, 17 insertions(+)

diff --git a/include/trace/syscall.h b/include/trace/syscall.h
index fed853f3d7aa..291c2824fafb 100644
--- a/include/trace/syscall.h
+++ b/include/trace/syscall.h
@@ -4,6 +4,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -32,4 +33,18 @@ struct syscall_metadata {
struct ftrace_event_call *exit_event;
 };
 
+#ifdef CONFIG_TRACEPOINTS
+static inline void syscall_tracepoint_update(struct task_struct *p)
+{
+   if (test_thread_flag(TIF_SYSCALL_TRACEPOINT))
+   set_tsk_thread_flag(p, TIF_SYSCALL_TRACEPOINT);
+   else
+   clear_tsk_thread_flag(p, TIF_SYSCALL_TRACEPOINT);
+}
+#else
+static inline void syscall_tracepoint_update(struct task_struct *p)
+{
+}
+#endif
+
 #endif /* _TRACE_SYSCALL_H */
diff --git a/kernel/fork.c b/kernel/fork.c
index d2799d1fc952..6a13c46cd87d 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -1487,7 +1487,9 @@ static struct task_struct *copy_process(unsigned long 
clone_flags,
 
total_forks++;
spin_unlock(>sighand->siglock);
+   syscall_tracepoint_update(p);
write_unlock_irq(_lock);
+
proc_fork_connector(p);
cgroup_post_fork(p);
if (clone_flags & CLONE_THREAD)
-- 
2.0.0.rc2


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

[for-next][PATCH 3/3] tracing: syscall_regfunc() should not skip kernel threads

[Steven Rostedt]

From: Oleg Nesterov 

syscall_regfunc() ignores the kernel threads because "it has no effect",
see cc3b13c1 "Don't trace kernel thread syscalls" which added this check.

However, this means that a user-space task spawned by call_usermodehelper()
will run without TIF_SYSCALL_TRACEPOINT if sys_tracepoint_refcount != 0.

Remove this check. The unnecessary report from ret_from_fork path mentioned
by cc3b13c1 is no longer possible, see See commit fb45550d76bb5 "make sure
that kernel_thread() callbacks call do_exit() themselves".

A kernel_thread() callback can only return and take the int_ret_from_sys_call
path after do_execve() succeeds, otherwise the kernel will crash. But in this
case it is no longer a kernel thread and thus is needs TIF_SYSCALL_TRACEPOINT.

Link: http://lkml.kernel.org/p/20140413185938.gd20...@redhat.com

Signed-off-by: Oleg Nesterov 
Signed-off-by: Steven Rostedt 
---
 kernel/tracepoint.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/kernel/tracepoint.c b/kernel/tracepoint.c
index 9cf12640de5a..3490407dc7b7 100644
--- a/kernel/tracepoint.c
+++ b/kernel/tracepoint.c
@@ -497,9 +497,7 @@ void syscall_regfunc(void)
if (!sys_tracepoint_refcount) {
read_lock(_lock);
for_each_process_thread(p, t) {
-   /* Skip kernel threads. */
-   if (!(t->flags & PF_KTHREAD))
-   set_tsk_thread_flag(t, TIF_SYSCALL_TRACEPOINT);
+   set_tsk_thread_flag(t, TIF_SYSCALL_TRACEPOINT);
}
read_unlock(_lock);
}
-- 
2.0.0.rc2


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

Re: [bisected] pre-3.16 regression on open() scalability

[Andi Kleen]

I still think it's totally the wrong direction to pollute so 
many fast paths with this obscure debugging check workaround
unconditionally.

cond_resched() is in EVERY sleeping lock and in EVERY memory allocation!
And these are really critical paths for many workloads.

If you really wanted to do this I think you would first need
to define a cond_resched_i_am_not_fast() or somesuch.

Or put it all behind some debugging ifdef.

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

[for-next][PATCH 2/3] tracing: Change syscall_*regfunc() to check PF_KTHREAD and use for_each_process_thread()

[Steven Rostedt]

From: Oleg Nesterov 

1. Remove _irqsafe from syscall_regfunc/syscall_unregfunc,
   read_lock(tasklist) doesn't need to disable irqs.

2. Change this code to avoid the deprecated do_each_thread()
   and use for_each_process_thread() (stolen from the patch
   from Frederic).

3. Change syscall_regfunc() to check PF_KTHREAD to skip
   the kernel threads, ->mm != NULL is the common mistake.

   Note: probably this check should be simply removed, needs
   another patch.

[fweis...@gmail.com: s/do_each_thread/for_each_process_thread/]
Link: http://lkml.kernel.org/p/20140413185918.gc20...@redhat.com

Signed-off-by: Oleg Nesterov 
Signed-off-by: Steven Rostedt 
---
 kernel/tracepoint.c | 24 +++-
 1 file changed, 11 insertions(+), 13 deletions(-)

diff --git a/kernel/tracepoint.c b/kernel/tracepoint.c
index 33cbd8c203f8..9cf12640de5a 100644
--- a/kernel/tracepoint.c
+++ b/kernel/tracepoint.c
@@ -492,33 +492,31 @@ static int sys_tracepoint_refcount;
 
 void syscall_regfunc(void)
 {
-   unsigned long flags;
-   struct task_struct *g, *t;
+   struct task_struct *p, *t;
 
if (!sys_tracepoint_refcount) {
-   read_lock_irqsave(_lock, flags);
-   do_each_thread(g, t) {
+   read_lock(_lock);
+   for_each_process_thread(p, t) {
/* Skip kernel threads. */
-   if (t->mm)
+   if (!(t->flags & PF_KTHREAD))
set_tsk_thread_flag(t, TIF_SYSCALL_TRACEPOINT);
-   } while_each_thread(g, t);
-   read_unlock_irqrestore(_lock, flags);
+   }
+   read_unlock(_lock);
}
sys_tracepoint_refcount++;
 }
 
 void syscall_unregfunc(void)
 {
-   unsigned long flags;
-   struct task_struct *g, *t;
+   struct task_struct *p, *t;
 
sys_tracepoint_refcount--;
if (!sys_tracepoint_refcount) {
-   read_lock_irqsave(_lock, flags);
-   do_each_thread(g, t) {
+   read_lock(_lock);
+   for_each_process_thread(p, t) {
clear_tsk_thread_flag(t, TIF_SYSCALL_TRACEPOINT);
-   } while_each_thread(g, t);
-   read_unlock_irqrestore(_lock, flags);
+   }
+   read_unlock(_lock);
}
 }
 #endif
-- 
2.0.0.rc2


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

[for-next][PATCH 0/3] [3.16 and stable] tracing: Fixes to syscall tracing

[Steven Rostedt]

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

Head SHA1: 72fa1a896d8ef355e81270667803ceb16a3dd13f


Oleg Nesterov (3):
  tracing: Fix syscall_*regfunc() vs copy_process() race
  tracing: Change syscall_*regfunc() to check PF_KTHREAD and use 
for_each_process_thread()
  tracing: syscall_regfunc() should not skip kernel threads


 include/trace/syscall.h | 15 +++
 kernel/fork.c   |  2 ++
 kernel/tracepoint.c | 26 +++---
 3 files changed, 28 insertions(+), 15 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] media: dib9000: avoid out of bound access

[Heinrich Schuchardt]

On 19.06.2014 01:50, Kees Cook wrote:

On Wed, Jun 18, 2014 at 3:02 PM, Heinrich Schuchardt  wrote:

The current test to avoid out of bound access to mb[] is insufficient.
For len = 19 non-existent mb[10] will be accessed.

A check in the for loop is insufficient to avoid out of bound access in
dib9000_mbx_send_attr.

Signed-off-by: Heinrich Schuchardt 
---
  drivers/media/dvb-frontends/dib9000.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/dib9000.c 
b/drivers/media/dvb-frontends/dib9000.c
index e540cfb..6a71917 100644
--- a/drivers/media/dvb-frontends/dib9000.c
+++ b/drivers/media/dvb-frontends/dib9000.c
@@ -1040,10 +1040,13 @@ static int dib9000_risc_apb_access_write(struct 
dib9000_state *state, u32 addres
 if (address >= 1024 || !state->platform.risc.fw_is_running)
 return -EINVAL;

+   if (len > 18)
+   return -EINVAL;
+
 /* dprintk( "APB access thru wr fw %d %x", address, attribute); */

 mb[0] = (unsigned short)address;
-   for (i = 0; i < len && i < 20; i += 2)
+   for (i = 0; i < len; i += 2)
 mb[1 + (i / 2)] = (b[i] << 8 | b[i + 1]);


Good catch on the mb[] access! However, I think there is still more to
fix since b[i + 1] can read past the end of b: Say b is defined as "u8
b[3]". Passing len 3 means the second loop, with i==2 will access b[2]
and b[3], the latter is out of range.


b[] and len are provided by the caller of dib9000_risc_apb_access_write.
dib9000_risc_apb_access_write cannot verify if the length of b[] matches 
len at all.


Currently dib9000_risc_apb_access_write cannot handle odd values of len. 
This holds even true if b[] has been padded with zero to an even length: 
For odd values of len the last byte is not passed to dib9000_mbx_send_attr.


What is left unclear is how odd values of len should be handled correctly:

Should the caller provide a b[] padded with 0 to the next even number of 
bytes,
or should dib9000_risc_apb_access_write take care not to read more then 
len bytes,

or should odd values of len cause an error EINVAL.

From what I read in the coding one source of the value of len is 
tuner_attach(), which is called from outside the dib9000 driver.


Heinrich



-Kees



 dib9000_mbx_send_attr(state, OUT_MSG_BRIDGE_APB_W, mb, 1 + len / 2, 
attribute);
--
2.0.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: [REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

[Greg KH]

On Wed, Jun 18, 2014 at 09:23:06PM -0400, Rob Clark wrote:
> On Wed, Jun 18, 2014 at 9:13 PM, Greg KH  wrote:
> > On Wed, Jun 18, 2014 at 12:36:54PM +0200, Maarten Lankhorst wrote:
> >> +#define CREATE_TRACE_POINTS
> >> +#include 
> >> +
> >> +EXPORT_TRACEPOINT_SYMBOL(fence_annotate_wait_on);
> >> +EXPORT_TRACEPOINT_SYMBOL(fence_emit);
> >
> > Are you really willing to live with these as tracepoints for forever?
> > What is the use of them in debugging?  Was it just for debugging the
> > fence code, or for something else?
> 
> fwiw, the goal is something like this:
> 
> http://people.freedesktop.org/~robclark/perf-supertuxkart.svg
> 
> but without needing to make perf understand each driver's custom trace events
> 
> (from: 
> http://bloggingthemonkey.blogspot.com/2013/09/freedreno-update-moar-fps.html
> )

Will these tracepoints provide something like that?  If so, great, but I
want to make sure as these now become a user/kernel ABI that you can not
break.

thanks,

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

Re: [trace:ftrace/core 1/3] include/trace/syscall.h:39:6: error: 'TIF_SYSCALL_TRACEPOINT' undeclared

[Steven Rostedt]

Hmm, removed Michael Halcrow as I'm guessing he no longer works for IBM.

On Wed, 18 Jun 2014 21:17:37 -0400
Steven Rostedt  wrote:

> On Wed, 18 Jun 2014 21:15:59 -0400
> Steven Rostedt  wrote:
> 
> > On Thu, 19 Jun 2014 03:25:46 +0800
> > kbuild test robot  wrote:
> > 
> > > tree:   
> > > git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git 
> > > ftrace/core
> > > head:   72fa1a896d8ef355e81270667803ceb16a3dd13f
> > > commit: 32def52ce8faec72c353b6304ca98176687e18f1 [1/3] tracing: Fix 
> > > syscall_*regfunc() vs copy_process() race
> > > config: make ARCH=xtensa allyesconfig
> > > 
> > > All error/warnings:
> > > 
> > >In file included from include/linux/syscalls.h:80:0,
> > > from fs/ecryptfs/keystore.c:29:
> > >include/trace/syscall.h: In function 'syscall_tracepoint_update':
> > > >> include/trace/syscall.h:39:6: error: 'TIF_SYSCALL_TRACEPOINT' 
> > > >> undeclared (first use in this function)
> > >include/trace/syscall.h:39:6: note: each undeclared identifier is 
> > > reported only once for each function it appears in
> > > 
> > > vim +/TIF_SYSCALL_TRACEPOINT +39 include/trace/syscall.h
> > > 
> > > 33struct ftrace_event_call *exit_event;
> > > 34};
> > > 35
> > > 36#ifdef CONFIG_TRACEPOINTS
> > > 37static inline void syscall_tracepoint_update(struct task_struct 
> > > *p)
> > > 38{
> > >   > 39if (test_thread_flag(TIF_SYSCALL_TRACEPOINT))
> > > 40set_tsk_thread_flag(p, TIF_SYSCALL_TRACEPOINT);
> > > 41else
> > > 42clear_tsk_thread_flag(p, 
> > > TIF_SYSCALL_TRACEPOINT);
> > > 
> > > ---
> > > 0-DAY kernel build testing backend  Open Source Technology 
> > > Center
> > > http://lists.01.org/mailman/listinfo/kbuild Intel 
> > > Corporation
> > 
> > My allyesconfig build passed with flying colors. Although we should
> 
> I should elaborate. I was building against mainline, I noticed that the
> kbuild test included linux-next.

My entire test suite passed. I'm not going to bother with adding the
header now, as it shouldn't affect mainline. I'm going to push my
changes up to linux-next tonight and push to Linus tomorrow.

The keystore.c shouldn't have included the syscall.h file, so if it
needs to be fixed before we get the thread_info.h in, they can just
remove it (my patch was attached to the previous email).

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

Re: Re: [RFT PATCH -next v3] [BUGFIX] kprobes: Fix "Failed to find blacklist" error on ia64 and ppc64

[Michael Ellerman]

On Wed, 2014-06-18 at 17:46 +0900, Masami Hiramatsu wrote:
> (2014/06/18 16:56), Michael Ellerman wrote:
> > On Fri, 2014-06-06 at 15:38 +0900, Masami Hiramatsu wrote:
> >> Ping?
> >>
> >> I guess this should go to 3.16 branch, shouldn't it?
> > 
> >>> diff --git a/arch/powerpc/include/asm/types.h 
> >>> b/arch/powerpc/include/asm/types.h
> >>> index bfb6ded..8b89d65 100644
> >>> --- a/arch/powerpc/include/asm/types.h
> >>> +++ b/arch/powerpc/include/asm/types.h
> >>> @@ -25,6 +25,17 @@ typedef struct {
> >>>   unsigned long env;
> >>>  } func_descr_t;
> >>>  
> >>> +#if defined(CONFIG_PPC64) && (!defined(_CALL_ELF) || _CALL_ELF == 1)
> >>> +/*
> >>> + * On PPC64 ABIv1 the function pointer actually points to the
> >>> + * function's descriptor. The first entry in the descriptor is the
> >>> + * address of the function text.
> >>> + */
> >>> +#define function_entry(fn)   (((func_descr_t *)(fn))->entry)
> >>> +#else
> >>> +#define function_entry(fn)   ((unsigned long)(fn))
> >>> +#endif
> > 
> > We already have ppc_function_entry(), can't you use that?
> 
> I'd like to ask you whether the address which ppc_function_entry() returns on
> PPC ABIv2 is really same address in kallsyms or not.
> As you can see, kprobes uses function_entry() to get the actual entry address
> where kallsyms knows. I have not much information about that, but it seems 
> that
> the "global entry point" is the address which kallsyms knows, isn't it?

OK. I'm not sure off the top of my head which address kallsyms knows about, but
yes it's likely that it is the global entry point.

I recently sent a patch to add ppc_global_function_entry(), because we need it
in the ftrace code. Once that is merged you could use that.

How do you hit the original problem, you don't actually specify in your commit
message? Something with kprobes obviously, but what exactly? I'll try and
reproduce it here.

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/

Re: [PATCH v2 0/5] Add glob pattern matching support on trigger and kprobe-event

[Steven Rostedt]

A blast from the past! (I'm cleaning out my inbox).

On Wed, 22 May 2013 11:19:03 +0900
Masami Hiramatsu  wrote:

> Hi,
> 
> Here is a series of ftrace/perf updates to support multiple
> event select operation by glob-based wild cards.
> 
> I've ported strglobmatch from perf-tools (with recursive call
> limitation) for this use. It is easier to use (just replacing
> strcmp) but slower than current parser-based matching.
> I don't care about the speed of matching because the all of
> the matching which I've introduced in this series are done
> on slow-path.
> 
> Changes in v2:
>  - Update the comment of patch [2/5] for explaining more
>detail of the backgroud.
> 
> ---
> 
> Masami Hiramatsu (5):
>   [BUGFIX] tracing: Returns -EBUSY when event_enable_func fails to get 
> module

This is applied.


>   perf: Swap the parameters of strglobmatch
>   lib/string: Add a generic wildcard string matching function
>   tracing/kprobes: Allow user to delete kprobe events by wild cards
>   tracing: Support enable/disable multiple events trigger by wild cards

These don't look to be applied. Looks like this patch series was lost.

Masami, are these still relevant?

-- Steve


> 
> 
>  Documentation/trace/ftrace.txt  |   12 ++-
>  Documentation/trace/kprobetrace.txt |   19 +++--
>  include/linux/string.h  |8 ++
>  kernel/trace/trace_events.c |  121 
> +--
>  kernel/trace/trace_kprobe.c |   97 
>  lib/string.c|   91 ++
>  tools/perf/util/parse-events.c  |   14 ++--
>  tools/perf/util/probe-event.c   |2 -
>  tools/perf/util/strfilter.c |2 -
>  tools/perf/util/string.c|   16 ++---
>  tools/perf/util/util.h  |4 +
>  11 files changed, 295 insertions(+), 91 deletions(-)
> 

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

Re: [PATCH] arch/score/include/asm/io.h: Add generic io map functions when MMU enabled

[Chen Gang]

On 06/19/2014 03:59 AM, Lennox Wu wrote:
> Hi Chen,
> Although "SuperH Timer Support" are never used in our platforms, we
> can still consider if these functions are necessary.
> Could you send the config to us?

It is allmodconfig under score for next-20140616, please check the
attachment for details.

Thanks.
-- 
Chen Gang

Open, share, and attitude like air, water, and life which God blessed


allmod_config.tar.gz
Description: GNU Zip compressed data

Re: [REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

[Rob Clark]

On Wed, Jun 18, 2014 at 9:16 PM, Greg KH  wrote:
> On Wed, Jun 18, 2014 at 12:36:54PM +0200, Maarten Lankhorst wrote:
>> A fence can be attached to a buffer which is being filled or consumed
>> by hw, to allow userspace to pass the buffer without waiting to another
>> device.  For example, userspace can call page_flip ioctl to display the
>> next frame of graphics after kicking the GPU but while the GPU is still
>> rendering.  The display device sharing the buffer with the GPU would
>> attach a callback to get notified when the GPU's rendering-complete IRQ
>> fires, to update the scan-out address of the display, without having to
>> wake up userspace.
>>
>> A driver must allocate a fence context for each execution ring that can
>> run in parallel. The function for this takes an argument with how many
>> contexts to allocate:
>>   + fence_context_alloc()
>>
>> A fence is transient, one-shot deal.  It is allocated and attached
>> to one or more dma-buf's.  When the one that attached it is done, with
>> the pending operation, it can signal the fence:
>>   + fence_signal()
>>
>> To have a rough approximation whether a fence is fired, call:
>>   + fence_is_signaled()
>>
>> The dma-buf-mgr handles tracking, and waiting on, the fences associated
>> with a dma-buf.
>>
>> The one pending on the fence can add an async callback:
>>   + fence_add_callback()
>>
>> The callback can optionally be cancelled with:
>>   + fence_remove_callback()
>>
>> To wait synchronously, optionally with a timeout:
>>   + fence_wait()
>>   + fence_wait_timeout()
>>
>> When emitting a fence, call:
>>   + trace_fence_emit()
>>
>> To annotate that a fence is blocking on another fence, call:
>>   + trace_fence_annotate_wait_on(fence, on_fence)
>>
>> A default software-only implementation is provided, which can be used
>> by drivers attaching a fence to a buffer when they have no other means
>> for hw sync.  But a memory backed fence is also envisioned, because it
>> is common that GPU's can write to, or poll on some memory location for
>> synchronization.  For example:
>>
>>   fence = custom_get_fence(...);
>>   if ((seqno_fence = to_seqno_fence(fence)) != NULL) {
>> dma_buf *fence_buf = seqno_fence->sync_buf;
>> get_dma_buf(fence_buf);
>>
>> ... tell the hw the memory location to wait ...
>> custom_wait_on(fence_buf, seqno_fence->seqno_ofs, fence->seqno);
>>   } else {
>> /* fall-back to sw sync * /
>> fence_add_callback(fence, my_cb);
>>   }
>>
>> On SoC platforms, if some other hw mechanism is provided for synchronizing
>> between IP blocks, it could be supported as an alternate implementation
>> with it's own fence ops in a similar way.
>>
>> enable_signaling callback is used to provide sw signaling in case a cpu
>> waiter is requested or no compatible hardware signaling could be used.
>>
>> The intention is to provide a userspace interface (presumably via eventfd)
>> later, to be used in conjunction with dma-buf's mmap support for sw access
>> to buffers (or for userspace apps that would prefer to do their own
>> synchronization).
>>
>> v1: Original
>> v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
>> that dma-fence didn't need to care about the sw->hw signaling path
>> (it can be handled same as sw->sw case), and therefore the fence->ops
>> can be simplified and more handled in the core.  So remove the signal,
>> add_callback, cancel_callback, and wait ops, and replace with a simple
>> enable_signaling() op which can be used to inform a fence supporting
>> hw->hw signaling that one or more devices which do not support hw
>> signaling are waiting (and therefore it should enable an irq or do
>> whatever is necessary in order that the CPU is notified when the
>> fence is passed).
>> v3: Fix locking fail in attach_fence() and get_fence()
>> v4: Remove tie-in w/ dma-buf..  after discussion w/ danvet and mlankorst
>> we decided that we need to be able to attach one fence to N dma-buf's,
>> so using the list_head in dma-fence struct would be problematic.
>> v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
>> v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some 
>> comments
>> about checking if fence fired or not. This is broken by design.
>> waitqueue_active during destruction is now fatal, since the signaller
>> should be holding a reference in enable_signalling until it signalled
>> the fence. Pass the original dma_fence_cb along, and call __remove_wait
>> in the dma_fence_callback handler, so that no cleanup needs to be
>> performed.
>> v7: [ Maarten Lankhorst ] Set cb->func and only enable sw signaling if
>> fence wasn't signaled yet, for example for hardware fences that may
>> choose to signal blindly.
>> v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
>> header and fixed include mess. dma-fence.h now includes dma-buf.h
>> All members 

Re: [REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

[Rob Clark]

On Wed, Jun 18, 2014 at 9:13 PM, Greg KH  wrote:
> On Wed, Jun 18, 2014 at 12:36:54PM +0200, Maarten Lankhorst wrote:
>> +#define CREATE_TRACE_POINTS
>> +#include 
>> +
>> +EXPORT_TRACEPOINT_SYMBOL(fence_annotate_wait_on);
>> +EXPORT_TRACEPOINT_SYMBOL(fence_emit);
>
> Are you really willing to live with these as tracepoints for forever?
> What is the use of them in debugging?  Was it just for debugging the
> fence code, or for something else?

fwiw, the goal is something like this:

http://people.freedesktop.org/~robclark/perf-supertuxkart.svg

but without needing to make perf understand each driver's custom trace events

(from: 
http://bloggingthemonkey.blogspot.com/2013/09/freedreno-update-moar-fps.html
)

BR,
-R


>> +/**
>> + * fence_context_alloc - allocate an array of fence contexts
>> + * @num: [in]amount of contexts to allocate
>> + *
>> + * This function will return the first index of the number of fences 
>> allocated.
>> + * The fence context is used for setting fence->context to a unique number.
>> + */
>> +unsigned fence_context_alloc(unsigned num)
>> +{
>> + BUG_ON(!num);
>> + return atomic_add_return(num, _context_counter) - num;
>> +}
>> +EXPORT_SYMBOL(fence_context_alloc);
>
> EXPORT_SYMBOL_GPL()?  Same goes for all of the exports in here.
> Traditionally all of the driver core exports have been with this
> marking, any objection to making that change here as well?
>
>> +int __fence_signal(struct fence *fence)
>> +{
>> + struct fence_cb *cur, *tmp;
>> + int ret = 0;
>> +
>> + if (WARN_ON(!fence))
>> + return -EINVAL;
>> +
>> + if (!ktime_to_ns(fence->timestamp)) {
>> + fence->timestamp = ktime_get();
>> + smp_mb__before_atomic();
>> + }
>> +
>> + if (test_and_set_bit(FENCE_FLAG_SIGNALED_BIT, >flags)) {
>> + ret = -EINVAL;
>> +
>> + /*
>> +  * we might have raced with the unlocked fence_signal,
>> +  * still run through all callbacks
>> +  */
>> + } else
>> + trace_fence_signaled(fence);
>> +
>> + list_for_each_entry_safe(cur, tmp, >cb_list, node) {
>> + list_del_init(>node);
>> + cur->func(fence, cur);
>> + }
>> + return ret;
>> +}
>> +EXPORT_SYMBOL(__fence_signal);
>
> Don't export a function with __ in front of it, you are saying that an
> internal function is somehow "valid" for everyone else to call?  Why?
> You aren't even documenting the function, so who knows how to use it?
>
>> +/**
>> + * fence_signal - signal completion of a fence
>> + * @fence: the fence to signal
>> + *
>> + * Signal completion for software callbacks on a fence, this will unblock
>> + * fence_wait() calls and run all the callbacks added with
>> + * fence_add_callback(). Can be called multiple times, but since a fence
>> + * can only go from unsignaled to signaled state, it will only be effective
>> + * the first time.
>> + */
>> +int fence_signal(struct fence *fence)
>> +{
>> + unsigned long flags;
>> +
>> + if (!fence)
>> + return -EINVAL;
>> +
>> + if (!ktime_to_ns(fence->timestamp)) {
>> + fence->timestamp = ktime_get();
>> + smp_mb__before_atomic();
>> + }
>> +
>> + if (test_and_set_bit(FENCE_FLAG_SIGNALED_BIT, >flags))
>> + return -EINVAL;
>> +
>> + trace_fence_signaled(fence);
>> +
>> + if (test_bit(FENCE_FLAG_ENABLE_SIGNAL_BIT, >flags)) {
>> + struct fence_cb *cur, *tmp;
>> +
>> + spin_lock_irqsave(fence->lock, flags);
>> + list_for_each_entry_safe(cur, tmp, >cb_list, node) {
>> + list_del_init(>node);
>> + cur->func(fence, cur);
>> + }
>> + spin_unlock_irqrestore(fence->lock, flags);
>> + }
>> + return 0;
>> +}
>> +EXPORT_SYMBOL(fence_signal);
>
> So, why should I use this over __fence_signal?  What is the difference?
> Am I missing some documentation somewhere?
>
>> +void release_fence(struct kref *kref)
>> +{
>> + struct fence *fence =
>> + container_of(kref, struct fence, refcount);
>> +
>> + trace_fence_destroy(fence);
>> +
>> + BUG_ON(!list_empty(>cb_list));
>> +
>> + if (fence->ops->release)
>> + fence->ops->release(fence);
>> + else
>> + kfree(fence);
>> +}
>> +EXPORT_SYMBOL(release_fence);
>
> fence_release() makes it more unified with the other functions in this
> file, right?
>
>> +/**
>> + * fence_default_wait - default sleep until the fence gets signaled
>> + * or until timeout elapses
>> + * @fence:   [in]the fence to wait on
>> + * @intr:[in]if true, do an interruptible wait
>> + * @timeout: [in]timeout value in jiffies, or MAX_SCHEDULE_TIMEOUT
>> + *
>> + * Returns -ERESTARTSYS if interrupted, 0 if the wait timed out, or the
>> + * remaining timeout in jiffies on success.
>> + */
>> +long
>
> Shouldn't this be signed to be explicit?
>
>> 

Re: relative objtree change broke tar builds?

[Ken Moffat]

On Wed, Jun 18, 2014 at 09:47:28PM +0200, Michal Marek wrote:
> 
> The idea is that one should be able to compare as much as possible
> between the build of /usr/src/linux- built in
> /usr/src/linux-/build and /usr/src/linux- built in
> /usr/src/linux-/build.

Michal,

 Now that you have sent a pull request to Linus, and therefore
addressed the main problem, may I dare to question your example ?

 I only started building kernels in (approximately) spring 2000, so I
am sure that I am missing a lot of history.  But /usr/src/linux*
smells of "tradition" in the Scots sense of "whit ma faither telt me
that his faither telt him" ("what my father told me that his father
told him" in english).  I am sure that /usr/src/linux might have been
an expectation in the distant past, but it tends to bring along the
assumption that kernels are _built_ by that dangerous guy called
'root'.

 Some of us (me included) often build things as root, but it has
many risks and people ought not to be led to believe it is
necessarily the correct way to do things.  Over the past 14 years I
have built kernels in ~/ as well as in other user-writable
directories and I am puzzled about why the idea of /usr/src/linux*
continues to exist.

ĸen
-- 
Nanny Ogg usually went to bed early. After all, she was an old lady.
Sometimes she went to bed as early as 6 a.m.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v7 0/4] net: Add APM X-Gene SoC Ethernet driver support

[Iyappan Subramanian]

Adding APM X-Gene SoC Ethernet driver.

v7: Address comments from v6 review
* fixed skb memory leak when dma_map_single fails in xmit.

v6: Address comments from v5 review
* added basic ethtool support
* added ndo_get_stats64 call back
* deleted priting Rx error messages
* renamed set_bits to xgene_set_bits to fix kbuild error (make ARCH=powerpc)

v5: Address comments from v4 review
* Documentation: Added phy-handle, reg-names and changed mdio part
* dtb: Added reg-names supplemental property
* changed platform_get_resource to platform_get_resource_byname
* added separate tx/rx set_desc/get_desc functions to do raw_write/raw_read
* removed set_desc/get_desc table lookup logic
* added error handling logic based on per packet descriptor bits
* added software managed Rx packet and error counters
* added busy wait for register read/writes
* changed mdio_bus->id to avoid conflict
* fixed mdio_bus leak in case of mdio_config error
* changed phy reg hard coded value to MII_BMSR
* changed phy addr hard coded value to phy_device->addr
* added paranthesis around macro arguments
* converted helper macros to inline functions
* changed use of goto's only to common work such as cleanup

v4: Address comments from v3 review
* MAINTAINERS: changed status to supported
* Kconfig: made default to no
* changed to bool data type wherever applicable
* cleaned up single bit set and masking code
* removed statistics counters masking
* removed unnecessary OOM message printing
* fixed dma_map_single and dma_unmap_single size parameter
* changed set bits macro body using new set_bits function

v3: Address comments from v2 review
* cleaned up set_desc and get_desc functions
* added dtb mdio node and phy-handle subnode
* renamed dtb phy-mode to phy-connection-type
* added of_phy_connect call to connec to PHY
* added empty line after last local variable declaration
* removed type casting when not required
* removed inline keyword from source files
* removed CONFIG_CPU_BIG_ENDIAN ifdef

v2
* Completely redesigned ethernet driver
* Added support to work with big endian kernel
* Renamed dtb phyid entry to phy_addr
* Changed dtb local-mac-address entry to byte string format
* Renamed dtb eth8clk entry to menetclk

v1
* Initial version

Signed-off-by: Iyappan Subramanian 
Signed-off-by: Ravi Patel 
Signed-off-by: Keyur Chudgar 
---

Iyappan Subramanian (4):
  MAINTAINERS: Add entry for APM X-Gene SoC ethernet driver
  Documentation: dts: Add bindings for APM X-Gene SoC ethernet driver
  dts: Add bindings for APM X-Gene SoC ethernet driver
  drivers: net: Add APM X-Gene SoC ethernet driver support.

 .../devicetree/bindings/net/apm-xgene-enet.txt |  72 ++
 MAINTAINERS|   8 +
 arch/arm64/boot/dts/apm-mustang.dts|   4 +
 arch/arm64/boot/dts/apm-storm.dtsi |  30 +-
 drivers/net/ethernet/Kconfig   |   1 +
 drivers/net/ethernet/Makefile  |   1 +
 drivers/net/ethernet/apm/Kconfig   |   1 +
 drivers/net/ethernet/apm/Makefile  |   5 +
 drivers/net/ethernet/apm/xgene/Kconfig |   9 +
 drivers/net/ethernet/apm/xgene/Makefile|   6 +
 .../net/ethernet/apm/xgene/xgene_enet_ethtool.c| 125 +++
 drivers/net/ethernet/apm/xgene/xgene_enet_hw.c | 848 +++
 drivers/net/ethernet/apm/xgene/xgene_enet_hw.h | 394 +
 drivers/net/ethernet/apm/xgene/xgene_enet_main.c   | 939 +
 drivers/net/ethernet/apm/xgene/xgene_enet_main.h   | 109 +++
 15 files changed, 2549 insertions(+), 3 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/apm-xgene-enet.txt
 create mode 100644 drivers/net/ethernet/apm/Kconfig
 create mode 100644 drivers/net/ethernet/apm/Makefile
 create mode 100644 drivers/net/ethernet/apm/xgene/Kconfig
 create mode 100644 drivers/net/ethernet/apm/xgene/Makefile
 create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_ethtool.c
 create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_hw.c
 create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_hw.h
 create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_main.c
 create mode 100644 drivers/net/ethernet/apm/xgene/xgene_enet_main.h

-- 
1.9.1

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

[PATCH v7 1/4] MAINTAINERS: Add entry for APM X-Gene SoC ethernet driver

[Iyappan Subramanian]

This patch adds a MAINTAINERS entry for APM X-Gene SoC
ethernet driver.

Signed-off-by: Iyappan Subramanian 
Signed-off-by: Ravi Patel 
Signed-off-by: Keyur Chudgar 
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 134483f..d65a3be 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -700,6 +700,14 @@ S: Maintained
 F: drivers/net/appletalk/
 F: net/appletalk/
 
+APPLIED MICRO (APM) X-GENE SOC ETHERNET DRIVER
+M: Iyappan Subramanian 
+M: Keyur Chudgar 
+M: Ravi Patel 
+S: Supported
+F: drivers/net/ethernet/apm/xgene/
+F: Documentation/devicetree/bindings/net/apm-xgene-enet.txt
+
 APTINA CAMERA SENSOR PLL
 M: Laurent Pinchart 
 L: linux-me...@vger.kernel.org
-- 
1.9.1

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

[PATCH v7 2/4] Documentation: dts: Add bindings for APM X-Gene SoC ethernet driver

[Iyappan Subramanian]

This patch adds documentation for APM X-Gene SoC ethernet DTS binding.

Signed-off-by: Iyappan Subramanian 
Signed-off-by: Ravi Patel 
Signed-off-by: Keyur Chudgar 
---
 .../devicetree/bindings/net/apm-xgene-enet.txt | 72 ++
 1 file changed, 72 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/apm-xgene-enet.txt

diff --git a/Documentation/devicetree/bindings/net/apm-xgene-enet.txt 
b/Documentation/devicetree/bindings/net/apm-xgene-enet.txt
new file mode 100644
index 000..3e2a295
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/apm-xgene-enet.txt
@@ -0,0 +1,72 @@
+APM X-Gene SoC Ethernet nodes
+
+Ethernet nodes are defined to describe on-chip ethernet interfaces in
+APM X-Gene SoC.
+
+Required properties:
+- compatible:  Should be "apm,xgene-enet"
+- reg: Address and length of the register set for the device. It contains the
+   information of registers in the same order as described by reg-names
+- reg-names: Should contain the register set names
+  "enet_csr":  Ethernet control and status register address space
+  "ring_csr":  Descriptor ring control and status register address 
space
+  "ring_cmd":  Descriptor ring command register address space
+- interrupts:  Ethernet main interrupt
+- clocks:  Reference to the clock entry.
+- local-mac-address:   MAC address assigned to this device
+- phy-connection-type: Interface type between ethernet device and PHY device
+- phy-handle:  Reference to a PHY node connected to this device
+
+- mdio:Device tree subnode with the following required
+   properties:
+
+   - compatible: Must be "apm,xgene-mdio".
+   - #address-cells: Must be <1>.
+   - #size-cells: Must be <0>.
+
+   For the phy on the mdio bus, there must be a node with the following
+   fields:
+
+   - compatible: PHY identifier.  Please refer ./phy.txt for the format.
+   - reg: The ID number for the phy.
+
+Optional properties:
+- status   : Should be "ok" or "disabled" for enabled/disabled.
+ Default is "ok".
+
+
+Example:
+   menetclk: menetclk {
+   compatible = "apm,xgene-device-clock";
+   clock-output-names = "menetclk";
+   status = "ok";
+   };
+
+   menet: ethernet@1702 {
+   compatible = "apm,xgene-enet";
+   status = "disabled";
+   reg = <0x0 0x1702 0x0 0xd100>,
+ <0x0 0X1703 0x0 0X400>,
+ <0x0 0X1000 0x0 0X200>;
+   reg-names = "enet_csr", "ring_csr", "ring_cmd";
+   interrupts = <0x0 0x3c 0x4>;
+   clocks = < 0>;
+   local-mac-address = [00 01 73 00 00 01];
+   phy-connection-type = "rgmii";
+   phy-handle = <>;
+   mdio {
+   compatible = "apm,xgene-mdio";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   menetphy: menetphy@3 {
+   compatible = "ethernet-phy-id001c.c915";
+   reg = <0x3>;
+   };
+
+   };
+   };
+
+/* Board-specific peripheral configurations */
+ {
+status = "ok";
+};
-- 
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: [trace:ftrace/core 1/3] include/trace/syscall.h:39:6: error: 'TIF_SYSCALL_TRACEPOINT' undeclared

[Steven Rostedt]

On Wed, 18 Jun 2014 21:15:59 -0400
Steven Rostedt  wrote:

> On Thu, 19 Jun 2014 03:25:46 +0800
> kbuild test robot  wrote:
> 
> > tree:   
> > git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git 
> > ftrace/core
> > head:   72fa1a896d8ef355e81270667803ceb16a3dd13f
> > commit: 32def52ce8faec72c353b6304ca98176687e18f1 [1/3] tracing: Fix 
> > syscall_*regfunc() vs copy_process() race
> > config: make ARCH=xtensa allyesconfig
> > 
> > All error/warnings:
> > 
> >In file included from include/linux/syscalls.h:80:0,
> > from fs/ecryptfs/keystore.c:29:
> >include/trace/syscall.h: In function 'syscall_tracepoint_update':
> > >> include/trace/syscall.h:39:6: error: 'TIF_SYSCALL_TRACEPOINT' undeclared 
> > >> (first use in this function)
> >include/trace/syscall.h:39:6: note: each undeclared identifier is 
> > reported only once for each function it appears in
> > 
> > vim +/TIF_SYSCALL_TRACEPOINT +39 include/trace/syscall.h
> > 
> > 33  struct ftrace_event_call *exit_event;
> > 34  };
> > 35  
> > 36  #ifdef CONFIG_TRACEPOINTS
> > 37  static inline void syscall_tracepoint_update(struct task_struct 
> > *p)
> > 38  {
> >   > 39  if (test_thread_flag(TIF_SYSCALL_TRACEPOINT))
> > 40  set_tsk_thread_flag(p, TIF_SYSCALL_TRACEPOINT);
> > 41  else
> > 42  clear_tsk_thread_flag(p, 
> > TIF_SYSCALL_TRACEPOINT);
> > 
> > ---
> > 0-DAY kernel build testing backend  Open Source Technology 
> > Center
> > http://lists.01.org/mailman/listinfo/kbuild Intel 
> > Corporation
> 
> My allyesconfig build passed with flying colors. Although we should

I should elaborate. I was building against mainline, I noticed that the
kbuild test included linux-next.

-- Steve

> probably still add the include of thread_info.h into trace/syscalls.h,
> there's no reason that ecryptfs/keystore.c includes linux/syscalls.h.
> 
> I suggest adding the patch below.
> 
> -- Steve
> 
> From 58029546c4acf896b9ce01a820e0093e37bb98be Mon Sep 17 00:00:00 2001
> From: "Steven Rostedt (Red Hat)" 
> Date: Wed, 18 Jun 2014 21:12:38 -0400
> Subject: [PATCH] ecryptfs: Remove unnecessary include of syscall.h in
>  keystore.c
> 
> There's no reason to include syscalls.h in keystore.c. Remove it.
> 
> Signed-off-by: Steven Rostedt 
> ---
>  fs/ecryptfs/keystore.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/fs/ecryptfs/keystore.c b/fs/ecryptfs/keystore.c
> index 4725a07f003c..831c5f8529be 100644
> --- a/fs/ecryptfs/keystore.c
> +++ b/fs/ecryptfs/keystore.c
> @@ -26,7 +26,6 @@
>   */
>  
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 

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

[PATCH v7 3/4] dts: Add bindings for APM X-Gene SoC ethernet driver

[Iyappan Subramanian]

This patch adds bindings for APM X-Gene SoC ethernet driver.

Signed-off-by: Iyappan Subramanian 
Signed-off-by: Ravi Patel 
Signed-off-by: Keyur Chudgar 
---
 arch/arm64/boot/dts/apm-mustang.dts |  4 
 arch/arm64/boot/dts/apm-storm.dtsi  | 30 +++---
 2 files changed, 31 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/apm-mustang.dts 
b/arch/arm64/boot/dts/apm-mustang.dts
index 1247ca1..e2fb1ef 100644
--- a/arch/arm64/boot/dts/apm-mustang.dts
+++ b/arch/arm64/boot/dts/apm-mustang.dts
@@ -24,3 +24,7 @@
reg = < 0x1 0x 0x0 0x8000 >; /* Updated by 
bootloader */
};
 };
+
+ {
+   status = "ok";
+};
diff --git a/arch/arm64/boot/dts/apm-storm.dtsi 
b/arch/arm64/boot/dts/apm-storm.dtsi
index c5f0a47..bd7a614 100644
--- a/arch/arm64/boot/dts/apm-storm.dtsi
+++ b/arch/arm64/boot/dts/apm-storm.dtsi
@@ -167,14 +167,13 @@
clock-output-names = "ethclk";
};
 
-   eth8clk: eth8clk {
+   menetclk: menetclk {
compatible = "apm,xgene-device-clock";
#clock-cells = <1>;
clocks = < 0>;
-   clock-names = "eth8clk";
reg = <0x0 0x1702C000 0x0 0x1000>;
reg-names = "csr-reg";
-   clock-output-names = "eth8clk";
+   clock-output-names = "menetclk";
};
 
sataphy1clk: sataphy1clk@1f21c000 {
@@ -363,5 +362,30 @@
#clock-cells = <1>;
clocks = < 0>;
};
+
+   menet: ethernet@1702 {
+   compatible = "apm,xgene-enet";
+   status = "disabled";
+   reg = <0x0 0x1702 0x0 0xd100>,
+ <0x0 0X1703 0x0 0X400>,
+ <0x0 0X1000 0x0 0X200>;
+   reg-names = "enet_csr", "ring_csr", "ring_cmd";
+   interrupts = <0x0 0x3c 0x4>;
+   dma-coherent;
+   clocks = < 0>;
+   local-mac-address = [00 01 73 00 00 01];
+   phy-connection-type = "rgmii";
+   phy-handle = <>;
+   mdio {
+   compatible = "apm,xgene-mdio";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   menetphy: menetphy@3 {
+   compatible = "ethernet-phy-id001c.c915";
+   reg = <0x3>;
+   };
+
+   };
+   };
};
 };
-- 
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: [ANNOUNCE] util-linux v2.25-rc1

[Anca Emanuel]

Can you help debian people (on the testing realm) to test this on all
architectures ?

On Wed, Jun 18, 2014 at 6:01 PM, Bruce Dubbs  wrote:
> Karel Zak wrote:
>>
>>
>> The util-linux release v2.25 is available at
>>
>>ftp://ftp.kernel.org/pub/linux/utils/util-linux/v2.25
>>
>> Feedback and bug reports, as always, are welcomed.
>
>
> In an LFS build environment, the configure, make, and make check are all
> clean.  It is especially nice the way you tell us why some tests are not run
> (mostly not root permissions).
>
> In prior releases, the last/ipv6 and last/last tests did not pass in the LFS
> environment, but they now do pass.
>
> It would be nice if we could set the adjtime path in configure.  Right now
> we do:
>
> sed -i -e 's@etc/adjtime@var/lib/hwclock/adjtime@g' \
>   $(grep -rl '/etc/adjtime' .)
>
>   -- Bruce
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [trace:ftrace/core 1/3] include/trace/syscall.h:39:6: error: 'TIF_SYSCALL_TRACEPOINT' undeclared

[Steven Rostedt]

On Thu, 19 Jun 2014 03:25:46 +0800
kbuild test robot  wrote:

> tree:   git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git 
> ftrace/core
> head:   72fa1a896d8ef355e81270667803ceb16a3dd13f
> commit: 32def52ce8faec72c353b6304ca98176687e18f1 [1/3] tracing: Fix 
> syscall_*regfunc() vs copy_process() race
> config: make ARCH=xtensa allyesconfig
> 
> All error/warnings:
> 
>In file included from include/linux/syscalls.h:80:0,
> from fs/ecryptfs/keystore.c:29:
>include/trace/syscall.h: In function 'syscall_tracepoint_update':
> >> include/trace/syscall.h:39:6: error: 'TIF_SYSCALL_TRACEPOINT' undeclared 
> >> (first use in this function)
>include/trace/syscall.h:39:6: note: each undeclared identifier is reported 
> only once for each function it appears in
> 
> vim +/TIF_SYSCALL_TRACEPOINT +39 include/trace/syscall.h
> 
> 33struct ftrace_event_call *exit_event;
> 34};
> 35
> 36#ifdef CONFIG_TRACEPOINTS
> 37static inline void syscall_tracepoint_update(struct task_struct 
> *p)
> 38{
>   > 39if (test_thread_flag(TIF_SYSCALL_TRACEPOINT))
> 40set_tsk_thread_flag(p, TIF_SYSCALL_TRACEPOINT);
> 41else
> 42clear_tsk_thread_flag(p, 
> TIF_SYSCALL_TRACEPOINT);
> 
> ---
> 0-DAY kernel build testing backend  Open Source Technology Center
> http://lists.01.org/mailman/listinfo/kbuild Intel Corporation

My allyesconfig build passed with flying colors. Although we should
probably still add the include of thread_info.h into trace/syscalls.h,
there's no reason that ecryptfs/keystore.c includes linux/syscalls.h.

I suggest adding the patch below.

-- Steve

>From 58029546c4acf896b9ce01a820e0093e37bb98be Mon Sep 17 00:00:00 2001
From: "Steven Rostedt (Red Hat)" 
Date: Wed, 18 Jun 2014 21:12:38 -0400
Subject: [PATCH] ecryptfs: Remove unnecessary include of syscall.h in
 keystore.c

There's no reason to include syscalls.h in keystore.c. Remove it.

Signed-off-by: Steven Rostedt 
---
 fs/ecryptfs/keystore.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/fs/ecryptfs/keystore.c b/fs/ecryptfs/keystore.c
index 4725a07f003c..831c5f8529be 100644
--- a/fs/ecryptfs/keystore.c
+++ b/fs/ecryptfs/keystore.c
@@ -26,7 +26,6 @@
  */
 
 #include 
-#include 
 #include 
 #include 
 #include 
-- 
2.0.0.rc2

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

Re: [PATCH RFC - TAKE TWO - 11/12] block, bfq: boost the throughput on NCQ-capable flash-based devices

[Tejun Heo]

Hello,

On Mon, Jun 16, 2014 at 12:46:36PM +0200, Paolo Valente wrote:
> To preserve the desired distribution of the device throughput (or time), this
> scheme entails updating weights every time the set of active queues changes.
> For example (sorry for the trivial example, but I just want to make sure that 
> I am
> not misunderstanding what you are telling me), suppose that two groups,
> A and B, are reserved 50% of the throughput each, and that the first group 
> contains
> two processes, whereas the second group just one process. Apart from the
> additional per-queue interventions of cfq to improve latency or throughput, 
> the
> queues the two processes in in group A are reserved 50% of the group 
> throughput
> each. It follows that, if all the three queues are backlogged, then a correct 
> weight
> distribution for a flat underlying scheduler is, e.g., 25 and 25 for the two 
> processes
> in group A, and 50 for the process in group B.
> 
> But, if one of the queues in group A becomes idle, then the correct weights
> of the still-active queues become, e.g., 50 and 50.

Yeap, that's what cfq is doing now.  Flattening priorities to the top
level each time the set of active queues changes.  It probably is
introducing weird artifacts to scheduling but given the existing
amount of existing noise I don't think it'd make a noticeable
difference.

> Changing weights this way has basically no influence of the per-request 
> latency
> guarantees of cfq, because cfq is based on a round-robin scheme, and the 
> latter
> already suffers from a large deviation with respect to an ideal service. In 
> contrast,
> things change dramatically with an accurate scheduler, such as the internal
> B-WF2Q+ scheduler of BFQ. In that case, as explained, e.g., here for packet
> scheduling (but the problem is exactly the same)
> 
> http://www.algogroup.unimore.it/people/paolo/dynWF2Q+/dynWF2Q+.pdf
> 
> weight changes would just break service guarantees, and lead to the same
> deviation as a round-robin scheduler. As proved in the same
> document, to preserve guarantees, weight updates should be delayed/concealed
> in a non-trivial (although computationally cheap) way.

Ah, bummer.  Flattening is so much easier to deal with.

> If useful, I am willing to provide more details, although these aspects are 
> most
> certainly quite theoretical and boring.

Including a simplified intuitive explanation of why fully hierarchical
scheduling is necessary with reference to more detailed explanation
would be nice.

> > Another thing I'm curious about is that the logic that you're using to
> > disable idling assumes that the disk will serve the queued commands
> > more or less in fair manner over time, right?  If so, why does queues
> > having the same weight matter?  Shouldn't the bandwidth scheduling
> > eventually make them converge to the specified weights over time?
> > Isn't wr_coeff > 1 test enough for maintaining reasonable
> > responsiveness?
> 
> Unfortunately, when I first defined bfq with Fabio, this was one of the main
> mistakes made in most of existing research I/O schedulers. More precisely, 
> your
> statement is true for async queues, but fails for sync queues. The problem is 
> that
> the (only) way in which a process pushes a scheduler into giving it its 
> reserved
> throughput is by issuing requests at a higher rate than that at which they are
> served. But, with sync queues this just cannot happen. In particular,
> postponing the service of a sync request delays the arrival of the next,
> but not-yet-arrived, sync request of the same process. Intuitively, for the 
> scheduler,
> it is like if the process was happy with the throughput it is receiving, 
> because
> it happens to issue requests exactly at that rate.
> 
> This problems is described in more detail, for example, in Section 5.3 of
> http://www.algogroup.unimore.it/people/paolo/disk_sched/bf1-v1-suite-results.pdf
> 
> bfq deals with this problem by properly back-shifting request timestamps when
> needed. But idling is necessary for this mechanism to work (unless more
> complex solutions are adopted).

Oh... I understand why idling is necessary to actually implement io
priorities.  I was wondering about the optimization for queued devices
and why it matters whether the active queues have equal weight or not.
If the optimization can be used for three of 1s, why can't it be used
for 1 and 2?

Thanks.

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

RE: [PATCH v6 07/10] x86, mpx: decode MPX instruction to get bound violation information

[Ren, Qiaowei]

On 2014-06-18, Borislav Petkov wrote:
> On Wed, Jun 18, 2014 at 05:44:13PM +0800, Qiaowei Ren wrote:
> 
> This whole insn decoding machinery above looks like adapted from
> arch/x86/lib/insn.c. You should merge it with the generic code in
> insn.c instead of homegrowing it here only for the purposes of MPX.
> And if it doesn't work for your needs, you should should extend the
> generic code to do so. I think we even talked about this last time.
> 
> Also, make sure you run all your patches through checkpatch.pl before
> submitting.
>
Petkov, as we discussed on initial version of this patchset, general insn 
framework didn't work out well and I have tried to use generic struct insn, 
insn_field, etc. for obvious benefits.

Thanks,
Qiaowei

Re: [REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

[Greg KH]

On Wed, Jun 18, 2014 at 12:36:54PM +0200, Maarten Lankhorst wrote:
> A fence can be attached to a buffer which is being filled or consumed
> by hw, to allow userspace to pass the buffer without waiting to another
> device.  For example, userspace can call page_flip ioctl to display the
> next frame of graphics after kicking the GPU but while the GPU is still
> rendering.  The display device sharing the buffer with the GPU would
> attach a callback to get notified when the GPU's rendering-complete IRQ
> fires, to update the scan-out address of the display, without having to
> wake up userspace.
> 
> A driver must allocate a fence context for each execution ring that can
> run in parallel. The function for this takes an argument with how many
> contexts to allocate:
>   + fence_context_alloc()
> 
> A fence is transient, one-shot deal.  It is allocated and attached
> to one or more dma-buf's.  When the one that attached it is done, with
> the pending operation, it can signal the fence:
>   + fence_signal()
> 
> To have a rough approximation whether a fence is fired, call:
>   + fence_is_signaled()
> 
> The dma-buf-mgr handles tracking, and waiting on, the fences associated
> with a dma-buf.
> 
> The one pending on the fence can add an async callback:
>   + fence_add_callback()
> 
> The callback can optionally be cancelled with:
>   + fence_remove_callback()
> 
> To wait synchronously, optionally with a timeout:
>   + fence_wait()
>   + fence_wait_timeout()
> 
> When emitting a fence, call:
>   + trace_fence_emit()
> 
> To annotate that a fence is blocking on another fence, call:
>   + trace_fence_annotate_wait_on(fence, on_fence)
> 
> A default software-only implementation is provided, which can be used
> by drivers attaching a fence to a buffer when they have no other means
> for hw sync.  But a memory backed fence is also envisioned, because it
> is common that GPU's can write to, or poll on some memory location for
> synchronization.  For example:
> 
>   fence = custom_get_fence(...);
>   if ((seqno_fence = to_seqno_fence(fence)) != NULL) {
> dma_buf *fence_buf = seqno_fence->sync_buf;
> get_dma_buf(fence_buf);
> 
> ... tell the hw the memory location to wait ...
> custom_wait_on(fence_buf, seqno_fence->seqno_ofs, fence->seqno);
>   } else {
> /* fall-back to sw sync * /
> fence_add_callback(fence, my_cb);
>   }
> 
> On SoC platforms, if some other hw mechanism is provided for synchronizing
> between IP blocks, it could be supported as an alternate implementation
> with it's own fence ops in a similar way.
> 
> enable_signaling callback is used to provide sw signaling in case a cpu
> waiter is requested or no compatible hardware signaling could be used.
> 
> The intention is to provide a userspace interface (presumably via eventfd)
> later, to be used in conjunction with dma-buf's mmap support for sw access
> to buffers (or for userspace apps that would prefer to do their own
> synchronization).
> 
> v1: Original
> v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
> that dma-fence didn't need to care about the sw->hw signaling path
> (it can be handled same as sw->sw case), and therefore the fence->ops
> can be simplified and more handled in the core.  So remove the signal,
> add_callback, cancel_callback, and wait ops, and replace with a simple
> enable_signaling() op which can be used to inform a fence supporting
> hw->hw signaling that one or more devices which do not support hw
> signaling are waiting (and therefore it should enable an irq or do
> whatever is necessary in order that the CPU is notified when the
> fence is passed).
> v3: Fix locking fail in attach_fence() and get_fence()
> v4: Remove tie-in w/ dma-buf..  after discussion w/ danvet and mlankorst
> we decided that we need to be able to attach one fence to N dma-buf's,
> so using the list_head in dma-fence struct would be problematic.
> v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
> v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some 
> comments
> about checking if fence fired or not. This is broken by design.
> waitqueue_active during destruction is now fatal, since the signaller
> should be holding a reference in enable_signalling until it signalled
> the fence. Pass the original dma_fence_cb along, and call __remove_wait
> in the dma_fence_callback handler, so that no cleanup needs to be
> performed.
> v7: [ Maarten Lankhorst ] Set cb->func and only enable sw signaling if
> fence wasn't signaled yet, for example for hardware fences that may
> choose to signal blindly.
> v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
> header and fixed include mess. dma-fence.h now includes dma-buf.h
> All members are now initialized, so kmalloc can be used for
> allocating a dma-fence. More documentation added.
> v9: Change compiler bitfields to 

Re: [REPOST PATCH 4/8] android: convert sync to fence api, v5

[Greg KH]

On Wed, Jun 18, 2014 at 12:37:11PM +0200, Maarten Lankhorst wrote:
> Just to show it's easy.
> 
> Android syncpoints can be mapped to a timeline. This removes the need
> to maintain a separate api for synchronization. I've left the android
> trace events in place, but the core fence events should already be
> sufficient for debugging.
> 
> v2:
> - Call fence_remove_callback in sync_fence_free if not all fences have fired.
> v3:
> - Merge Colin Cross' bugfixes, and the android fence merge optimization.
> v4:
> - Merge with the upstream fixes.
> v5:
> - Fix small style issues pointed out by Thomas Hellstrom.
> 
> Signed-off-by: Maarten Lankhorst 
> Acked-by: John Stultz 
> ---
>  drivers/staging/android/Kconfig  |1 
>  drivers/staging/android/Makefile |2 
>  drivers/staging/android/sw_sync.c|6 
>  drivers/staging/android/sync.c   |  913 
> +++---
>  drivers/staging/android/sync.h   |   79 ++-
>  drivers/staging/android/sync_debug.c |  247 +
>  drivers/staging/android/trace/sync.h |   12 
>  7 files changed, 609 insertions(+), 651 deletions(-)
>  create mode 100644 drivers/staging/android/sync_debug.c

With these changes, can we pull the android sync logic out of
drivers/staging/ now?

thanks,

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

Re: [REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

[Greg KH]

On Wed, Jun 18, 2014 at 12:36:54PM +0200, Maarten Lankhorst wrote:
> + * 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.

I don't like this paragraph in all of the files, but if you insist that
some lawyer wants it there, I'll live with it...

> + * You should have received a copy of the GNU General Public License along 
> with
> + * this program.  If not, see .

That's just not needed at all and is fluff.  Please remove.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [REPOST PATCH 1/8] fence: dma-buf cross-device synchronization (v17)

[Greg KH]

On Wed, Jun 18, 2014 at 12:36:54PM +0200, Maarten Lankhorst wrote:
> +#define CREATE_TRACE_POINTS
> +#include 
> +
> +EXPORT_TRACEPOINT_SYMBOL(fence_annotate_wait_on);
> +EXPORT_TRACEPOINT_SYMBOL(fence_emit);

Are you really willing to live with these as tracepoints for forever?
What is the use of them in debugging?  Was it just for debugging the
fence code, or for something else?

> +/**
> + * fence_context_alloc - allocate an array of fence contexts
> + * @num: [in]amount of contexts to allocate
> + *
> + * This function will return the first index of the number of fences 
> allocated.
> + * The fence context is used for setting fence->context to a unique number.
> + */
> +unsigned fence_context_alloc(unsigned num)
> +{
> + BUG_ON(!num);
> + return atomic_add_return(num, _context_counter) - num;
> +}
> +EXPORT_SYMBOL(fence_context_alloc);

EXPORT_SYMBOL_GPL()?  Same goes for all of the exports in here.
Traditionally all of the driver core exports have been with this
marking, any objection to making that change here as well?

> +int __fence_signal(struct fence *fence)
> +{
> + struct fence_cb *cur, *tmp;
> + int ret = 0;
> +
> + if (WARN_ON(!fence))
> + return -EINVAL;
> +
> + if (!ktime_to_ns(fence->timestamp)) {
> + fence->timestamp = ktime_get();
> + smp_mb__before_atomic();
> + }
> +
> + if (test_and_set_bit(FENCE_FLAG_SIGNALED_BIT, >flags)) {
> + ret = -EINVAL;
> +
> + /*
> +  * we might have raced with the unlocked fence_signal,
> +  * still run through all callbacks
> +  */
> + } else
> + trace_fence_signaled(fence);
> +
> + list_for_each_entry_safe(cur, tmp, >cb_list, node) {
> + list_del_init(>node);
> + cur->func(fence, cur);
> + }
> + return ret;
> +}
> +EXPORT_SYMBOL(__fence_signal);

Don't export a function with __ in front of it, you are saying that an
internal function is somehow "valid" for everyone else to call?  Why?
You aren't even documenting the function, so who knows how to use it?

> +/**
> + * fence_signal - signal completion of a fence
> + * @fence: the fence to signal
> + *
> + * Signal completion for software callbacks on a fence, this will unblock
> + * fence_wait() calls and run all the callbacks added with
> + * fence_add_callback(). Can be called multiple times, but since a fence
> + * can only go from unsignaled to signaled state, it will only be effective
> + * the first time.
> + */
> +int fence_signal(struct fence *fence)
> +{
> + unsigned long flags;
> +
> + if (!fence)
> + return -EINVAL;
> +
> + if (!ktime_to_ns(fence->timestamp)) {
> + fence->timestamp = ktime_get();
> + smp_mb__before_atomic();
> + }
> +
> + if (test_and_set_bit(FENCE_FLAG_SIGNALED_BIT, >flags))
> + return -EINVAL;
> +
> + trace_fence_signaled(fence);
> +
> + if (test_bit(FENCE_FLAG_ENABLE_SIGNAL_BIT, >flags)) {
> + struct fence_cb *cur, *tmp;
> +
> + spin_lock_irqsave(fence->lock, flags);
> + list_for_each_entry_safe(cur, tmp, >cb_list, node) {
> + list_del_init(>node);
> + cur->func(fence, cur);
> + }
> + spin_unlock_irqrestore(fence->lock, flags);
> + }
> + return 0;
> +}
> +EXPORT_SYMBOL(fence_signal);

So, why should I use this over __fence_signal?  What is the difference?
Am I missing some documentation somewhere?

> +void release_fence(struct kref *kref)
> +{
> + struct fence *fence =
> + container_of(kref, struct fence, refcount);
> +
> + trace_fence_destroy(fence);
> +
> + BUG_ON(!list_empty(>cb_list));
> +
> + if (fence->ops->release)
> + fence->ops->release(fence);
> + else
> + kfree(fence);
> +}
> +EXPORT_SYMBOL(release_fence);

fence_release() makes it more unified with the other functions in this
file, right?

> +/**
> + * fence_default_wait - default sleep until the fence gets signaled
> + * or until timeout elapses
> + * @fence:   [in]the fence to wait on
> + * @intr:[in]if true, do an interruptible wait
> + * @timeout: [in]timeout value in jiffies, or MAX_SCHEDULE_TIMEOUT
> + *
> + * Returns -ERESTARTSYS if interrupted, 0 if the wait timed out, or the
> + * remaining timeout in jiffies on success.
> + */
> +long

Shouldn't this be signed to be explicit?

> +fence_default_wait(struct fence *fence, bool intr, signed long timeout)
> +{
> + struct default_wait_cb cb;
> + unsigned long flags;
> + long ret = timeout;
> + bool was_set;
> +
> + if (test_bit(FENCE_FLAG_SIGNALED_BIT, >flags))
> + return timeout;
> +
> + spin_lock_irqsave(fence->lock, flags);
> +
> + if (intr && signal_pending(current)) {
> + ret = -ERESTARTSYS;
> + goto out;
> + }
> +
> + was_set = 

Re: [PATCH 2/3] w1: use pr_* instead of printk

[Joe Perches]

On Thu, 2014-06-19 at 02:52 +0200, Fjodor Schelichow wrote:
> This patch replaces all calls to the "printk" function within the main "w1"
> directory by calls to the appropriate "pr_*" function thus addressing
> the following warning generated by the checkpatch script:
[]
> diff --git a/drivers/w1/w1_log.h b/drivers/w1/w1_log.h
[]
> @@ -29,8 +29,8 @@
>  #else
>  #  define assert(expr) \
>  if(unlikely(!(expr))) {  \
> -printk(KERN_ERR "Assertion failed! %s,%s,%s,line=%d\n",  \
> - #expr, __FILE__, __func__, __LINE__);   \
> + pr_err("Assertion failed! %s,%s,%s,line=%d\n",  \
> + #expr, __FILE__, __func__, __LINE__);   \
>  }

These macros should really be surrounded by a do { ... } while (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/