[PATCH 3.4 00/25] 3.4.74-stable review

[Greg Kroah-Hartman]

This is the start of the stable review cycle for the 3.4.74 release.
There are 25 patches in this series, all will be posted as a response
to this one.  If anyone has any issues with these being applied, please
let me know.

Responses should be made by Thu Dec 12 07:59:15 UTC 2013.
Anything received after that time might be too late.

The whole patch series can be found in one patch at:
kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.74-rc1.gz
and the diffstat can be found below.

thanks,

greg k-h

-
Pseudo-Shortlog of commits:

Greg Kroah-Hartman 
Linux 3.4.74-rc1

Alan Cox 
drivers/char/i8k.c: add Dell XPLS L421X

David Cluytens 
USB: cdc-acm: Added support for the Lenovo RD02-D400 USB Modem

Colin Leitner 
USB: spcp8x5: correct handling of CS5 setting

Colin Leitner 
USB: mos7840: correct handling of CS5 setting

Colin Leitner 
USB: pl2303: fixed handling of CS5 setting

Seth Heasley 
i2c: i801: SMBus patch for Intel Avoton DeviceIDs

Seth Heasley 
ahci: AHCI-mode SATA patch for Intel Avoton DeviceIDs

James Ralston 
ahci: Add Device IDs for Intel Lynx Point-LP PCH

Sergei Trofimovich 
um: add missing declaration of 'getrlimit()' and friends

Tom Gundersen 
Input: mousedev - allow disabling even without CONFIG_EXPERT

Tom Gundersen 
Input: allow deselecting serio drivers even without CONFIG_EXPERT

Shawn Landden 
net: update consumers of MSG_MORE to recognize MSG_SENDPAGE_NOTLAST

Laxman Dewangan 
irq: Enable all irqs unconditionally in irq_resume

Liu Gang 
powerpc/gpio: Fix the wrong GPIO input data on MPC8572/MPC8536

Trond Myklebust 
NFSv4: Update list of irrecoverable errors on DELEGRETURN

Linus Walleij 
net: smc91: fix crash regression on the versatile

Stephen M. Cameron 
SCSI: hpsa: return 0 from driver probe function on success, not 1

Stephen M. Cameron 
SCSI: hpsa: do not discard scsi status on aborted commands

Dan Williams 
SCSI: libsas: fix usage of ata_tf_to_fis

James Bottomley 
SCSI: enclosure: fix WARN_ON in dual path device removing

Bo Shen 
ASoC: wm8731: fix dsp mode configuration

Mark Brown 
ASoC: wm8990: Mark the register map as dirty when powering down

Tom Lendacky 
crypto: authenc - Find proper IV address in ablkcipher callback

Horia Geanta 
crypto: ccm - Fix handling of zero plaintext when computing mac

Tom Lendacky 
crypto: scatterwalk - Set the chain pointer indication bit


-

Diffstat:

 Documentation/i2c/busses/i2c-i801  |  1 +
 Makefile   |  4 ++--
 arch/um/os-Linux/start_up.c|  2 ++
 crypto/algif_hash.c|  3 +++
 crypto/algif_skcipher.c|  3 +++
 crypto/authenc.c   |  7 ---
 crypto/ccm.c   |  3 ++-
 drivers/ata/ahci.c | 24 
 drivers/char/i8k.c |  7 +++
 drivers/gpio/gpio-mpc8xxx.c|  8 ++--
 drivers/i2c/busses/Kconfig |  1 +
 drivers/i2c/busses/i2c-i801.c  |  3 +++
 drivers/input/Kconfig  |  2 +-
 drivers/input/keyboard/Kconfig |  4 ++--
 drivers/input/serio/Kconfig|  6 +++---
 drivers/misc/enclosure.c   |  7 +++
 drivers/net/ethernet/smsc/smc91x.h | 22 --
 drivers/scsi/hpsa.c|  4 ++--
 drivers/scsi/libsas/sas_ata.c  |  2 +-
 drivers/usb/class/cdc-acm.c|  2 ++
 drivers/usb/serial/mos7840.c   | 32 
 drivers/usb/serial/pl2303.c| 32 +++-
 drivers/usb/serial/spcp8x5.c   | 30 ++
 fs/nfs/nfs4proc.c  | 10 --
 include/crypto/scatterwalk.h   |  1 +
 kernel/irq/pm.c|  2 +-
 net/ipv4/udp.c |  3 +++
 sound/soc/codecs/wm8731.c  |  4 ++--
 sound/soc/codecs/wm8990.c  |  2 ++
 29 files changed, 142 insertions(+), 89 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] ALSA: at73c213: clk_round_rate() can return a zero upon error

[Takashi Iwai]

At Mon, 9 Dec 2013 18:40:48 -0800,
Paul Walmsley wrote:
> 
> 
> Treat both negative and zero return values from clk_round_rate()
> as errors.  This is needed since subsequent patches will convert
> clk_round_rate()'s return value to be an unsigned type, rather
> than a signed type, since some clock sources can generate rates higher 
> than (2^31)-1 Hz.
> 
> Eventually, when calling clk_round_rate(), only a return value of
> zero will be considered a error.  All other values will be
> considered valid rates.  The comparison against values less than
> 0 is kept to preserve the correct behavior in the meantime.
> 
> Signed-off-by: Paul Walmsley 
> Cc: Hans-Christian Egtvedt 
> Cc: Takashi Iwai 
> Cc: Jaroslav Kysela 
> ---
> Applies on v3.13-rc3.  See also:
> 
> http://marc.info/?l=linux-arm-kernel&m=138542591313620&w=2

Is the behavior "returning zero upon error" already in 3.13?  That is,
should this (and another) patch be taken as a 3.13-fix patch, or it's
for 3.14?


thanks,

Takashi


> 
>   sound/spi/at73c213.c |2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sound/spi/at73c213.c b/sound/spi/at73c213.c
> index 8e3d9a6c7a3b..25c38afaee49 100644
> --- a/sound/spi/at73c213.c
> +++ b/sound/spi/at73c213.c
> @@ -174,7 +174,7 @@ static int snd_at73c213_set_bitrate(struct snd_at73c213 
> *chip)
>   dac_rate_new = 8 * (ssc_rate / ssc_div);
> 
>   status = clk_round_rate(chip->board->dac_clk, dac_rate_new);
> - if (status < 0)
> + if (status <= 0)
>   return status;
> 
>   /* Ignore difference smaller than 256 Hz. */
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 security fix never sent to -stable?

[Greg KH]

On Tue, Dec 10, 2013 at 10:55:23AM +1100, Dave Chinner wrote:
> [cc xfs list, cc sta...@vger.kernel.org]
> 
> On Mon, Dec 09, 2013 at 08:17:09AM -0500, Josh Boyer wrote:
> > On Mon, Dec 9, 2013 at 7:15 AM, Luis Henriques
> >  wrote:
> > > On Thu, Dec 05, 2013 at 04:35:50PM -0800, Kees Cook wrote:
> > >> Hi,
> > >>
> > >> It looks like 8c567a7fab6e086a0284eee2db82348521e7120c ("xfs: add
> > >> capability check to free eofblocks ioctl") is a security fix that was
> > >> never sent to -stable? From what I can see, it was introduced in 3.8
> > >> by 8ca149de80478441352a8622ea15fae7de703ced ("xfs: add
> > >> XFS_IOC_FREE_EOFBLOCKS ioctl").
> > >>
> > >> I don't see this in the 3.8.y tree. Should it be added there and newer?
> > >
> > > Thanks Kees, I'm queuing it for the 3.11 kernel.
> > 
> > There's also this one:
> > 
> > http://thread.gmane.org/gmane.comp.file-systems.xfs.general/57654
> > 
> > It fixes CVE-2013-6382
> 
> First I've heard about it there being a CVE for that bug. Since when
> has it been considered best practice to publish CVEs without first
> (or ever) directly contacting the relevant upstream developers?
> 
> But, regardless of how broken I think the CVE process is, commit
> 071c529 ("xfs: underflow bug in xfs_attrlist_by_handle()") should be
> picked up by the stable kernels.

I don't see that commit in Linus's tree, is it not there yet?

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/

[GIT PULL REQUEST] watchdog - v3.13-rc3 Fixes

[Wim Van Sebroeck]

Hi Linus,

Please pull from 'master' branch of
git://www.linux-watchdog.org/linux-watchdog.git

It will drop the unnecessary miscdevice.h includes that we forgot in
commit 487722cf2 and fix an oops for the sc1200_wdt driver.

This will update the following files:

 bcm2835_wdt.c  |1 -
 ep93xx_wdt.c   |1 -
 ie6xx_wdt.c|1 -
 jz4740_wdt.c   |1 -
 kempld_wdt.c   |1 -
 max63xx_wdt.c  |1 -
 orion_wdt.c|1 -
 pnx4008_wdt.c  |1 -
 rt2880_wdt.c   |1 -
 sc1200wdt.c|3 ++-
 shwdt.c|1 -
 softdog.c  |1 -
 stmp3xxx_rtc_wdt.c |1 -
 txx9wdt.c  |1 -
 ux500_wdt.c|1 -
 15 files changed, 2 insertions(+), 15 deletions(-)

with these Changes:

commit dace8bbfccfd9e4fcccfffcfbd82881fda3e756f
Author: Alan 
Date:   Wed Dec 4 15:31:52 2013 +

sc1200_wdt: Fix oops

If loaded with isapnp = 0 the driver explodes. This is catching
people out now and then. What should happen in the working case is
a complete mystery and the code appears terminally confused, but we
can at least make the error path work properly.

Signed-off-by: Alan Cox 
Reviewed-by: Guenter Roeck 
Signed-off-by: Wim Van Sebroeck 
Partially-Resolves-bug: https://bugzilla.kernel.org/show_bug.cgi?id=53991

commit 9539210e17dc09ea1472076c297d461c7507a5bb
Author: Guenter Roeck 
Date:   Tue Nov 19 13:26:17 2013 -0800

watchdog: Drop unnecessary include of miscdevice.h

After commit 487722cf2 (watchdog: Get rid of MODULE_ALIAS_MISCDEV
statements) the affected drivers no longer need to include miscdevice.h.
Only exception is rt2880_wdt.c which never needed it.

Signed-off-by: Guenter Roeck 
Reviewed-by: Jean Delvare 
Signed-off-by: Wim Van Sebroeck 

For completeness, I added the overal diff below.

Greetings,
Wim.


diff --git a/drivers/watchdog/bcm2835_wdt.c b/drivers/watchdog/bcm2835_wdt.c
index a6a2ceb..cafa973 100644
--- a/drivers/watchdog/bcm2835_wdt.c
+++ b/drivers/watchdog/bcm2835_wdt.c
@@ -19,7 +19,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #define PM_RSTC0x1c
 #define PM_WDOG0x24
diff --git a/drivers/watchdog/ep93xx_wdt.c b/drivers/watchdog/ep93xx_wdt.c
index 833e813..d1d07f2 100644
--- a/drivers/watchdog/ep93xx_wdt.c
+++ b/drivers/watchdog/ep93xx_wdt.c
@@ -28,7 +28,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/watchdog/ie6xx_wdt.c b/drivers/watchdog/ie6xx_wdt.c
index 70a2402..07f88f5 100644
--- a/drivers/watchdog/ie6xx_wdt.c
+++ b/drivers/watchdog/ie6xx_wdt.c
@@ -28,7 +28,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/watchdog/jz4740_wdt.c b/drivers/watchdog/jz4740_wdt.c
index 2de486a..3aa50cf 100644
--- a/drivers/watchdog/jz4740_wdt.c
+++ b/drivers/watchdog/jz4740_wdt.c
@@ -17,7 +17,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/watchdog/kempld_wdt.c b/drivers/watchdog/kempld_wdt.c
index a1a3638..20dc738 100644
--- a/drivers/watchdog/kempld_wdt.c
+++ b/drivers/watchdog/kempld_wdt.c
@@ -26,7 +26,6 @@
 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/watchdog/max63xx_wdt.c b/drivers/watchdog/max63xx_wdt.c
index 6d4f399..bdb3f4a 100644
--- a/drivers/watchdog/max63xx_wdt.c
+++ b/drivers/watchdog/max63xx_wdt.c
@@ -19,7 +19,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c
index 44edca6..f7722a4 100644
--- a/drivers/watchdog/orion_wdt.c
+++ b/drivers/watchdog/orion_wdt.c
@@ -16,7 +16,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/watchdog/pnx4008_wdt.c b/drivers/watchdog/pnx4008_wdt.c
index 1bdcc31..5bec20f 100644
--- a/drivers/watchdog/pnx4008_wdt.c
+++ b/drivers/watchdog/pnx4008_wdt.c
@@ -23,7 +23,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
diff --git a/drivers/watchdog/rt2880_wdt.c b/drivers/watchdog/rt2880_wdt.c
index 53d37fe..d92c2d5 100644
--- a/drivers/watchdog/rt2880_wdt.c
+++ b/drivers/watchdog/rt2880_wdt.c
@@ -16,7 +16,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
diff --git a/drivers/watchdog/sc1200wdt.c b/drivers/watchdog/sc1200wdt.c
index 3b9fff9..131193a 100644
--- a/drivers/watchdog/sc1200wdt.c
+++ b/drivers/watchdog/sc1200wdt.c
@@ -409,8 +409,9 @@ static int __init sc1200wdt_init(void)
 #if defined CONFIG_PNP
/* now that the user has specified an IO port and we haven't detected
 * any devices, disable pnp support */
+   if (isapnp)
+   pnp_unregister_driver(&scl200wdt_pnp_driver);
isapnp = 0;
-   pnp_unregister_

Re: [PATCH] devtmpfs: Calling delete_path() only when necessary

[Greg Kroah-Hartman]

On Tue, Dec 10, 2013 at 03:26:33PM +0800, Fengguang Wu wrote:
> > Hi, Fengguang
> > Can you help to add this patch to your test systems?
> > It's a one-line change, you can find the patch at
> > https://patchwork.kernel.org/patch/3192361/
> 
> Hi Axel,
> 
> Do you have a public git tree? If not, I'd like to take this chance to
> encourage you to setup one. The best work flow is to create a branch,
> apply the patch and tell me the git URL and branch name to test.

Unless you have a bunch of devices added and removed from the system
dynamically, you really aren't going to hit this codepath, so I don't
think your automated system really is going to help out much here,
sorry.

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

[GIT PULL] AVR32 fixes for 3.13

[Hans-Christian Egtvedt]

Hello Linus,

please pull

git://git.kernel.org/pub/scm/linux/kernel/git/egtvedt/linux-avr32.git for-linus

to receive the following AVR32 fixes for 3.13

Matthias Brugger (2):
  avr32: pm: Fix section mismatch
  cpufreq_ at32ap-cpufreq.c: Fix section mismatch

Eunbong Song (1):
  avr32: Kill CONFIG_MTD_PARTITIONS

Michael Opdenacker (1):
  avr32: remove deprecated IRQF_DISABLED

Paul Walmsley (1):
  avr32: favr-32: clk_round_rate() can return a zero upon error

 arch/avr32/boards/favr-32/setup.c   | 4 +++-
 arch/avr32/configs/atngw100_defconfig   | 1 -
 arch/avr32/configs/atngw100_evklcd100_defconfig | 1 -
 arch/avr32/configs/atngw100_evklcd101_defconfig | 1 -
 arch/avr32/configs/atngw100_mrmt_defconfig  | 1 -
 arch/avr32/configs/atngw100mkii_defconfig   | 1 -
 arch/avr32/configs/atngw100mkii_evklcd100_defconfig | 1 -
 arch/avr32/configs/atngw100mkii_evklcd101_defconfig | 1 -
 arch/avr32/configs/atstk1002_defconfig  | 1 -
 arch/avr32/configs/atstk1003_defconfig  | 1 -
 arch/avr32/configs/atstk1004_defconfig  | 1 -
 arch/avr32/configs/atstk1006_defconfig  | 1 -
 arch/avr32/configs/favr-32_defconfig| 1 -
 arch/avr32/configs/hammerhead_defconfig | 1 -
 arch/avr32/configs/merisc_defconfig | 1 -
 arch/avr32/configs/mimc200_defconfig| 1 -
 arch/avr32/kernel/time.c| 2 +-
 arch/avr32/mach-at32ap/pm.c | 2 +-
 drivers/cpufreq/at32ap-cpufreq.c| 2 +-
 19 files changed, 6 insertions(+), 19 deletions(-)

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

mqueue perf data

[Wanlong Gao]

Hi Fengguang,


Do we need to stat out the perf data of mqueue test in kernel_selftests?
It's like following.

Thanks,
Wanlong Gao



# make run_tests -C mqueue
make: Entering directory `/git/linux/tools/testing/selftests/mqueue'

Initial system state:
Using queue path:   /test1
RLIMIT_MSGQUEUE(soft):  819200
RLIMIT_MSGQUEUE(hard):  819200
Maximum Message Size:   8192
Maximum Queue Size: 10
Default Message Size:   8192
Default Queue Size: 10

Adjusted system state for testing:
RLIMIT_MSGQUEUE(soft):  819200
RLIMIT_MSGQUEUE(hard):  819200
Maximum Message Size:   8192
Maximum Queue Size: 10
Default Message Size:   8192
Default Queue Size: 10


Test series 1, behavior when no attr struct passed to mq_open:
Kernel supports setting defaults separately from maximums:  PASS
Given sane values, mq_open without an attr struct succeeds: PASS
Kernel properly honors default setting knobs:   PASS
Kernel properly limits default values to lesser of default/max: PASS
Kernel properly fails to create queue when defaults would
exceed rlimit:  PASS


Test series 2, behavior when attr struct is passed to mq_open:
Queue open in excess of rlimit max when euid = 0 failed:PASS
Queue open with mq_maxmsg > limit when euid = 0 succeeded:  PASS
Queue open with mq_msgsize > limit when euid = 0 succeeded: PASS
Queue open with total size > 2GB when euid = 0 failed:  PASS
Queue open in excess of rlimit max when euid = 99 failed:   PASS
Queue open with mq_maxmsg > limit when euid = 99 failed:PASS
Queue open with mq_msgsize > limit when euid = 99 failed:   PASS
Queue open with total size > 2GB when euid = 99 failed: PASS

Initial system state:
Using queue path:   /mq_perf_tests
RLIMIT_MSGQUEUE(soft):  819200
RLIMIT_MSGQUEUE(hard):  819200
Maximum Message Size:   8192
Maximum Queue Size: 10
Nice value: 0

Adjusted system state for testing:
RLIMIT_MSGQUEUE(soft):  (unlimited)
RLIMIT_MSGQUEUE(hard):  (unlimited)
Maximum Message Size:   16777216
Maximum Queue Size: 65530
Nice value: -20
Continuous mode:(disabled)
CPUs to pin:3

Queue /mq_perf_tests created:
mq_flags:   O_NONBLOCK
mq_maxmsg:  65530
mq_msgsize: 16
mq_curmsgs: 0

Started mqueue performance test thread on CPU 3
Max priorities: 32768
Clock resolution:   1 nsec

Test #1: Time send/recv message, queue empty
(1000 iterations)
Send msg:   4.50690280s total time
405 nsec/msg
Recv msg:   4.123621560s total time
412 nsec/msg

Test #2a: Time send/recv message, queue full, constant prio
(10 iterations)
Filling queue...done.   0.14554407s
Testing...done.
Send msg:   0.40292962s total time
402 nsec/msg
Recv msg:   0.40605786s total time
406 nsec/msg
Draining queue...done.  0.15010003s

Test #2b: Time send/recv message, queue full, increasing prio
(10 iterations)
Filling queue...done.   0.25628197s
Testing...done.
Send msg:   0.53792862s total time
537 nsec/msg
Recv msg:   0.52323416s total time
523 nsec/msg
Draining queue...done.  0.17617835s

Test #2c: Time send/recv message, queue full, decreasing prio
(10 iterations)
Filling queue...done.   0.26939894s
Testing...done.
Send msg:   0.55733128s total time
557 nsec/msg
 

Re: [patch] mm, page_alloc: allow __GFP_NOFAIL to allocate below watermarks after reclaim

[Mel Gorman]

On Mon, Dec 09, 2013 at 02:03:45PM -0800, David Rientjes wrote:
> If direct reclaim has failed to free memory, __GFP_NOFAIL allocations
> can potentially loop forever in the page allocator.  In this case, it's
> better to give them the ability to access below watermarks so that they
> may allocate similar to the same privilege given to GFP_ATOMIC
> allocations.
> 
> We're careful to ensure this is only done after direct reclaim has had
> the chance to free memory, however.
> 
> Signed-off-by: David Rientjes 

The main problem with doing something like this is that it just smacks
into the adjusted watermark if there are a number of __GFP_NOFAIL. Who
was the user of __GFP_NOFAIL that was fixed by this patch?

It appears there are more __GFP_NOFAIL users than I expected and some of
them are silly. md uses it after mempool_alloc fails GFP_ATOMIC and then
immediately calls with __GFP_NOFAIL in a context that can sleep. It could
just have used GFP_NOIO for the mempool alloc which would "never" fail.

btrfs is using __GFP_NOFAIL to call the slab allocator for the extent
cache but also a kmalloc cache which is just dangerous. After this
patch, that thing can push the system below watermarks and then
effectively "leak" them to other !__GFP_NOFAIL users.

Buffer cache uses __GFP_NOFAIL to grow buffers where it expects the page
allocator can loop endlessly but again, allowing it to go below reserves
is just going to hit the same wall a short time later

gfs is using the flag with kmalloc slabs, same as btrfs this can "leak"
the reserves. jbd is the same although jbd2 avoids using the flag in a
manner of speaking.

There are enough bad users of __GFP_NOFAIL that I really question how
good an idea it is to allow emergency reserves to be used when they are
potentially leaked to other !__GFP_NOFAIL users via the slab allocator
shortly afterwards.

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

Re: [PATCH] Make the mtdblock read/write skip the bad nand sector

[Brian Norris]

On Fri, Nov 29, 2013 at 02:26:53PM +0100, Pavel Machek wrote:
> > >  > Thanks a lot for the insight. After reading this, I'm wondering what's
> > >  > preventing us from killing MTD block support altogether. Artem, already
> > >  > suggested it a while back...
> > > 
> > > People using squashfs/cramfs/readonly ext2/.. on a NOR flash?
> > 
> > And people who *still*, after all these years, don't realise that they
> > don't actually need it to mount JFFS2. Even as the root file system
> > (although they *do* need rootfstype=jffs2).
> 
> I must admit I'm such person...

Even the Kconfig disagrees with David :)

config MTD_BLOCK
tristate "Caching block device access to MTD devices"
...
  At the moment, it is also required for the Journalling Flash File
  System(s) to obtain a handle on the MTD device when it's mounted
  (although JFFS and JFFS2 don't actually use any of the functionality
  of the mtdblock device).

The website is more forthcoming, but it still says it's needed for the
rootfs:

  http://linux-mtd.infradead.org/faq/jffs2.html#L_mtdblock

So I suppose we really need to clean this up, eh?

...

> (Should not mtdblock be at least in devices.txt file?)

Probably.

> BTW... is there documentation of mtdblock "translation layer"
> somewhere? I realize it is very simple, but it does need to keep some
> data?

There's a bit scattered around the MTD website, but this FAQ has a
little:

  http://linux-mtd.infradead.org/faq/general.html#L_ext2_mtd

Really, the "translation" is truly dead simple; I believe it is simply
an identity mapping, where the mtd is mapped linearly to the mtdblock.
So address X in /dev/mtdY is address X in /dev/mtdblockY.

> I guess running jffs on regular block device (USB stick, SD card) is
> not feasible?

http://linux-mtd.infradead.org/faq/jffs2.html#L_stick_jffs2

Brian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] ARM: bcm_defconfig: Unset CONFIG_CRYPTO_ANSI_CPRNG

[Christian Daudt]

On Thu, Dec 5, 2013 at 3:00 PM, Tim Kryger  wrote:
> Do not build the Pseudo Random Number Generation for Cryptographic
> modules since it is not currently being used for this platform.
>
> Signed-off-by: Tim Kryger 
> Reviewed-by: Markus Mayer 
> ---
>  arch/arm/configs/bcm_defconfig | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/arch/arm/configs/bcm_defconfig b/arch/arm/configs/bcm_defconfig
> index 574e046..ef03bba 100644
> --- a/arch/arm/configs/bcm_defconfig
> +++ b/arch/arm/configs/bcm_defconfig
> @@ -119,6 +119,7 @@ CONFIG_DETECT_HUNG_TASK=y
>  CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=110
>  CONFIG_BOOTPARAM_HUNG_TASK_PANIC=y
>  # CONFIG_FTRACE is not set
> +# CONFIG_CRYPTO_ANSI_CPRNG is not set
>  CONFIG_CRC_CCITT=y
>  CONFIG_CRC_T10DIF=y
>  CONFIG_CRC_ITU_T=y
> --
> 1.8.0.1
>
Applied to armsoc/for-3.14/soc

 thanks
  csd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 04/10] PCI: Destroy pci dev only once

[Ethan Zhao]

On Tue, Dec 10, 2013 at 3:08 AM, Greg Kroah-Hartman
 wrote:
> On Mon, Dec 09, 2013 at 11:24:04PM +0800, Ethan Zhao wrote:
>> On Sun, Dec 8, 2013 at 11:50 AM, Greg Kroah-Hartman
>>  wrote:
>> > On Sat, Dec 07, 2013 at 07:31:21PM -0800, Yinghai Lu wrote:
>> >> [+ GregKH]
>> >>
>> >> On Fri, Dec 6, 2013 at 5:27 PM, Rafael J. Wysocki  
>> >> wrote:
>> >> > On Thursday, December 05, 2013 10:52:36 PM Yinghai Lu wrote:
>> >> >> On Mon, Dec 2, 2013 at 6:49 AM, Rafael J. Wysocki  
>> >> >> wrote:
>> >> >> >
>> >> >> > Scenario 5: pci_stop_and_remove_bus_device() is run concurrently
>> >> >> >   for a device and its parent bridge via remove_callback().
>> >> >> >
>> >> >> >   In that case both code paths attempt to acquire
>> >> >> >   pci_remove_rescan_mutex.  If the child device removal acquires
>> >> >> >   it first, there will be no problems.  However, if the parent
>> >> >> >   bridge removal acquires it first, it will eventually execute
>> >> >> >   pci_destroy_dev() for the child device, but that device will
>> >> >> >   not be freed yet due to the reference held by the concurrent
>> >> >> >   child removal.  Consequently, both pci_stop_bus_device() and
>> >> >> >   pci_remove_bus_device() will be executed for that device
>> >> >> >   unnecessarily and pci_destroy_dev() will see a corrupted list
>> >> >> >   head in that object.  Moreover, an excess put_device() will
>> >> >> >   be executed for that device in that case which may lead to a
>> >> >> >   use-after-free in the final kobject_put() done by
>> >> >> >   sysfs_schedule_callback_work().
>> >> >> >
>> >> >> > Index: linux-pm/include/linux/pci.h
>> >> >> > ===
>> >> >> > --- linux-pm.orig/include/linux/pci.h
>> >> >> > +++ linux-pm/include/linux/pci.h
>> >> >> > @@ -321,6 +321,7 @@ struct pci_dev {
>> >> >> > unsigned intmultifunction:1;/* Part of multi-function 
>> >> >> > device */
>> >> >> > /* keep track of device state */
>> >> >> > unsigned intis_added:1;
>> >> >> > +   unsigned intis_gone:1;
>> >> >> > unsigned intis_busmaster:1; /* device is busmaster */
>> >> >> > unsigned intno_msi:1;   /* device may not use msi */
>> >> >> > unsigned intblock_cfg_access:1; /* config space 
>> >> >> > access is blocked */
>> >> >> > Index: linux-pm/drivers/pci/remove.c
>> >> >> > ===
>> >> >> > --- linux-pm.orig/drivers/pci/remove.c
>> >> >> > +++ linux-pm/drivers/pci/remove.c
>> >> >> > @@ -34,6 +34,7 @@ static void pci_stop_dev(struct pci_dev
>> >> >> >
>> >> >> >  static void pci_destroy_dev(struct pci_dev *dev)
>> >> >> >  {
>> >> >> > +   dev->is_gone = 1;
>> >> >> > device_del(&dev->dev);
>> >> >> >
>> >> >> > down_write(&pci_bus_sem);
>> >> >> > @@ -109,8 +110,10 @@ static void pci_remove_bus_device(struct
>> >> >> >   */
>> >> >> >  void pci_stop_and_remove_bus_device(struct pci_dev *dev)
>> >> >> >  {
>> >> >> > -   pci_stop_bus_device(dev);
>> >> >> > -   pci_remove_bus_device(dev);
>> >> >> > +   if (!dev->is_gone) {
>> >> >> > +   pci_stop_bus_device(dev);
>> >> >> > +   pci_remove_bus_device(dev);
>> >> >> > +   }
>> >> >> >  }
>> >> >> >  EXPORT_SYMBOL(pci_stop_and_remove_bus_device);
>> >> >> >
>> >> >>
>> >> >> Yes, above change should address sys double remove problem.
>> >> >
>> >> > I've just realized that we don't need a new flag for that, though.
>> >> >
>> >> > It looks like we only need to check dev->dev.kobj.parent and return if 
>> >> > that is
>> >> > NULL, because that means pci_destroy_dev() has run for that device 
>> >> > already
>> >> > (I'm wondering why device_del() doesn't clear dev->parent, BTW, it 
>> >> > looks like
>> >> > it should do that?).
>> >> >
>> >> > Of course, that still is going to be racy if we don't hold
>> >> > pci_remove_rescan_mutex around pci_stop_and_remove_bus_device() in 
>> >> > every code
>> >> > path using it (or use another similar synchronization mechanism).
>> >>
>> >> Wonder if we can have safe way to check if device_del() is called already.
>> >
>> > Nope.
>> >
>> >> And those access_after_free should be addressed by driver core instead
>> >> of pci code?
>> >
>> > Nope, it's up to the bus to handle this.  It shouldn't be hard, you
>> > shouldn't actually care about this, if you do, something is wrong.
>> >
>> > How is this PCI code so hard to get right?  Look at USB for devices that
>> > disappear from anywhere at anytime as an example for how to handle
>> > this.  PCI should be doing the same thing, no need for this "is_gone"
>> > stuff.
>> Greg,
>>
>>   Don't agree USB is a good example to follow, do you never hit panic
>> when you pull out USB device from anywhere at anytime without unmount
>> or stop it via command ?
>
> You shouldn't.  If you do, it's a bug, let us know and we will fix it.

Of coz, next time hit, bore you

Re: [RESEND PATCH] ARM: bcm_defconfig: Do not expect appended DTB

[Christian Daudt]

On Thu, Dec 5, 2013 at 3:30 PM, Tim Kryger  wrote:
> The bootloaders used with Broadcom mobile SoCs are capable of handling
> a device tree separately from the zImage so there is no need for this
> option to be enabled.
>
> Signed-off-by: Tim Kryger 
> Reviewed-by: Markus Mayer 
> ---
>  arch/arm/configs/bcm_defconfig | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm/configs/bcm_defconfig b/arch/arm/configs/bcm_defconfig
> index 6e49310..b152367 100644
> --- a/arch/arm/configs/bcm_defconfig
> +++ b/arch/arm/configs/bcm_defconfig
> @@ -35,7 +35,6 @@ CONFIG_AEABI=y
>  # CONFIG_COMPACTION is not set
>  CONFIG_ZBOOT_ROM_TEXT=0x0
>  CONFIG_ZBOOT_ROM_BSS=0x0
> -CONFIG_ARM_APPENDED_DTB=y
>  CONFIG_CMDLINE="console=ttyS0,115200n8 mem=128M"
>  CONFIG_CPU_IDLE=y
>  CONFIG_VFP=y
> --
> 1.8.0.1
>
Applied to armsoc/for-3.14/soc

 thanks,
  csd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] avr32: favr-32: clk_round_rate() can return a zero upon error

[Hans-Christian Egtvedt]

Around Mon 09 Dec 2013 18:35:24 -0800 or thereabout, Paul Walmsley wrote:
> 
> Treat both negative and zero return values from clk_round_rate() as
> errors.  This is needed since subsequent patches will convert
> clk_round_rate()'s return value to be an unsigned type, rather than a
> signed type, since some clock sources can generate rates higher than
> (2^31)-1 Hz.
> 
> Eventually, when calling clk_round_rate(), only a return value of zero
> will be considered a error.  All other values will be considered valid
> rates.  The comparison against values less than 0 is kept to preserve
> the correct behavior in the meantime.
> 
> Signed-off-by: Paul Walmsley 
> Cc: Nicolas Ferre 
> Cc: Håvard Skinnemoen 
> Cc: Hans-Christian Egtvedt 
> Cc: Jean-Christophe PLAGNIOL-VILLARD 

Thanks for fixing, applied to for-linus branch in
git://git.kernel.org/pub/scm/linux/kernel/git/egtvedt/linux-avr32.git

Acked-by: Hans-Christian Egtvedt 

> ---
> Applies on v3.13-rc3.  See also:
> 
> http://marc.info/?l=linux-arm-kernel&m=138542591313620&w=2
> 
>  arch/avr32/boards/favr-32/setup.c |4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/arch/avr32/boards/favr-32/setup.c 
> b/arch/avr32/boards/favr-32/setup.c
> index 7b1f2cd85400..1f121497b517 100644
> --- a/arch/avr32/boards/favr-32/setup.c
> +++ b/arch/avr32/boards/favr-32/setup.c
> @@ -298,8 +298,10 @@ static int __init set_abdac_rate(struct platform_device 
> *pdev)
>*/
>   retval = clk_round_rate(pll1,
>   CONFIG_BOARD_FAVR32_ABDAC_RATE * 256 * 16);
> - if (retval < 0)
> + if (retval <= 0) {
> + retval = -EINVAL;
>   goto out_abdac;
> + }
> 
>   retval = clk_set_rate(pll1, retval);
>   if (retval != 0)


-- 
mvh
Hans-Christian Egtvedt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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: at73c213: clk_round_rate() can return a zero upon error

[Hans-Christian Egtvedt]

Around Mon 09 Dec 2013 18:40:48 -0800 or thereabout, Paul Walmsley wrote:
> 
> Treat both negative and zero return values from clk_round_rate()
> as errors.  This is needed since subsequent patches will convert
> clk_round_rate()'s return value to be an unsigned type, rather
> than a signed type, since some clock sources can generate rates
> higher than (2^31)-1 Hz.
> 
> Eventually, when calling clk_round_rate(), only a return value of
> zero will be considered a error.  All other values will be
> considered valid rates.  The comparison against values less than
> 0 is kept to preserve the correct behavior in the meantime.
> 
> Signed-off-by: Paul Walmsley 
> Cc: Hans-Christian Egtvedt 
> Cc: Takashi Iwai 
> Cc: Jaroslav Kysela 

Thanks for fixing.

Acked-by: Hans-Christian Egtvedt 

> ---
> Applies on v3.13-rc3.  See also:
> 
> http://marc.info/?l=linux-arm-kernel&m=138542591313620&w=2
> 
>  sound/spi/at73c213.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sound/spi/at73c213.c b/sound/spi/at73c213.c
> index 8e3d9a6c7a3b..25c38afaee49 100644
> --- a/sound/spi/at73c213.c
> +++ b/sound/spi/at73c213.c
> @@ -174,7 +174,7 @@ static int snd_at73c213_set_bitrate(struct snd_at73c213 
> *chip)
>   dac_rate_new = 8 * (ssc_rate / ssc_div);
> 
>   status = clk_round_rate(chip->board->dac_clk, dac_rate_new);
> - if (status < 0)
> + if (status <= 0)
>   return status;
> 
>   /* Ignore difference smaller than 256 Hz. */
> 

-- 
mvh
Hans-Christian Egtvedt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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: atmel_abdac: clk_round_rate() can return a zero upon error

[Hans-Christian Egtvedt]

Around Mon 09 Dec 2013 18:49:13 -0800 or thereabout, Paul Walmsley wrote:
> 
> Treat both negative and zero return values from clk_round_rate()
> as errors.  This is needed since subsequent patches will convert
> clk_round_rate()'s return value to be an unsigned type, rather
> than a signed type, since some clock sources can generate rates higher
> than (2^31)-1 Hz.
> 
> Eventually, when calling clk_round_rate(), only a return value of
> zero will be considered a error; all other values will be
> considered valid rates.  The comparison against values less than
> 0 is kept to preserve the correct behavior in the meantime.
> 
> Signed-off-by: Paul Walmsley 
> Cc: Hans-Christian Egtvedt 
> Cc: Nicolas Ferre 
> Cc: Takashi Iwai 
> Cc: Jaroslav Kysela 

Thanks for fixing.

Acked-by: Hans-Christian Egtvedt 

> ---
> Applies on v3.13-rc3.  See also:
> 
> http://marc.info/?l=linux-arm-kernel&m=138542591313620&w=2
> 
>  sound/atmel/abdac.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/sound/atmel/abdac.c b/sound/atmel/abdac.c
> index 721d8fd..3519518 100644
> --- a/sound/atmel/abdac.c
> +++ b/sound/atmel/abdac.c
> @@ -354,7 +354,7 @@ static int set_sample_rates(struct atmel_abdac *dac)
>   /* we start at 192 kHz and work our way down to 5112 Hz */
>   while (new_rate >= RATE_MIN && index < (MAX_NUM_RATES + 1)) {
>   new_rate = clk_round_rate(dac->sample_clk, 256 * new_rate);
> - if (new_rate < 0)
> + if (new_rate <= 0)
>   break;
>   /* make sure we are below the ABDAC clock */
>   if (index < MAX_NUM_RATES &&
> 

-- 
mvh
Hans-Christian Egtvedt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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/9] PCI: Use dev_is_pci() to check whether it is pci device

[Yijing Wang]

On 2013/12/10 8:01, Bjorn Helgaas wrote:
> [+cc arch lists]
> 
> On Thu, Dec 05, 2013 at 07:52:53PM +0800, Yijing Wang wrote:
>> Use dev_is_pci() instead of directly compare
>> pci_bus_type to check whether it is pci device.
>>
>> Signed-off-by: Yijing Wang 
> 
> I applied all these to my pci/yijing-dev_is_pci branch for v3.14, thanks!
> 
> Browse them here: 
> http://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/yijing-dev_is_pci

Thanks!
Bjorn, I sent the "[patch v2 4/9] sparc/PCI: Use dev_is_pci() to identify PCI 
devices" to
correct build error found by kbuild test, Because I have no sparc platform, I 
guess the build error was introduced
by I remove the CONFIG_PCI #ifdef in that patch. Now I keep the CONFIG_PCI code 
and that patch should be no functional change.


> 
> This should be no functional change.
> 
>  arch/alpha/kernel/pci_iommu.c|2 +-
>  arch/arm/common/it8152.c |4 ++--
>  arch/arm/mach-ixp4xx/common-pci.c|6 +++---
>  arch/ia64/hp/common/sba_iommu.c  |2 +-
>  arch/ia64/sn/pci/pci_dma.c   |   24 
>  arch/parisc/kernel/drivers.c |   22 +-
>  arch/powerpc/sysdev/fsl_pci.c|2 +-
>  arch/sparc/include/asm/dma-mapping.h |   10 --
>  arch/sparc/kernel/iommu.c|2 +-
>  arch/sparc/kernel/ioport.c   |4 +---
>  arch/x86/kernel/acpi/boot.c  |4 +---
>  drivers/pci/pci-acpi.c   |2 +-
>  12 files changed, 33 insertions(+), 51 deletions(-)
> 
> Bjorn
> 
>> ---
>>  drivers/pci/pci-acpi.c |2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/drivers/pci/pci-acpi.c b/drivers/pci/pci-acpi.c
>> index 577074e..e0431f1 100644
>> --- a/drivers/pci/pci-acpi.c
>> +++ b/drivers/pci/pci-acpi.c
>> @@ -358,7 +358,7 @@ static void pci_acpi_cleanup(struct device *dev)
>>  
>>  static bool pci_acpi_bus_match(struct device *dev)
>>  {
>> -return dev->bus == &pci_bus_type;
>> +return dev_is_pci(dev);
>>  }
>>  
>>  static struct acpi_bus_type acpi_pci_bus = {
>> -- 
>> 1.7.1
>>
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> .
> 


-- 
Thanks!
Yijing

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

Re: [PATCH V7 2/2] arm64: perf: add support for percpu pmu interrupt

[Vinayak Kale]

Hi Will,


On Mon, Dec 9, 2013 at 10:20 PM, Will Deacon  wrote:
> Hi Vinayak,
>
> On Wed, Dec 04, 2013 at 10:09:51AM +, Vinayak Kale wrote:
>> Add support for irq registration when pmu interrupt is percpu.
>
> Getting closer...
>
>> Signed-off-by: Vinayak Kale 
>> Signed-off-by: Tuan Phan 
>> ---
>>  arch/arm64/kernel/perf_event.c |  108 
>> +---
>>  1 file changed, 78 insertions(+), 30 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
>> index cea1594..d8e6667 100644
>> --- a/arch/arm64/kernel/perf_event.c
>> +++ b/arch/arm64/kernel/perf_event.c
>> @@ -22,6 +22,7 @@
>>
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>  #include 
>> @@ -363,26 +364,52 @@ validate_group(struct perf_event *event)
>>  }
>>
>>  static void
>> +armpmu_disable_percpu_irq(void *data)
>> +{
>> + disable_percpu_irq((long)data);
>> +}
>
> Given that we wait for the CPUs to finish enabling/disabling the IRQ, I
> actually meant pass the pointer to the IRQ, which removes the horrible
> casts in the caller.
>
>> + if (irq_is_percpu(irq)) {
>> + cpumask_clear(&armpmu->active_irqs);
>
> Thanks for moving the mask manipulation out. It now makes it obvious that we
> don't care about the mask at all for PPIs, so that can be removed (the code
> you have is racy against hotplug anyway).
>
> I took the liberty of writing a fixup for you (see below). Can you test it
> on your platform please?

Below fixup works fine on APM platform.
Do you want me to send this fixup as part of next revision of the
patch or will you apply it yourself? (For later case, you have my ack)

>
> Cheers,
>
> Will
>
> --->8
>
> diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
> index 503c1eeedc1c..5b1cd792274a 100644
> --- a/arch/arm64/kernel/perf_event.c
> +++ b/arch/arm64/kernel/perf_event.c
> @@ -366,7 +366,8 @@ validate_group(struct perf_event *event)
>  static void
>  armpmu_disable_percpu_irq(void *data)
>  {
> -   disable_percpu_irq((long)data);
> +   unsigned int irq = *(unsigned int *)data;
> +   disable_percpu_irq(irq);
>  }
>
>  static void
> @@ -385,8 +386,7 @@ armpmu_release_hardware(struct arm_pmu *armpmu)
> return;
>
> if (irq_is_percpu(irq)) {
> -   cpumask_clear(&armpmu->active_irqs);
> -   on_each_cpu(armpmu_disable_percpu_irq, (void *)(long)irq, 1);
> +   on_each_cpu(armpmu_disable_percpu_irq, &irq, 1);
> free_percpu_irq(irq, &cpu_hw_events);
> } else {
> for (i = 0; i < irqs; ++i) {
> @@ -402,7 +402,8 @@ armpmu_release_hardware(struct arm_pmu *armpmu)
>  static void
>  armpmu_enable_percpu_irq(void *data)
>  {
> -   enable_percpu_irq((long)data, IRQ_TYPE_NONE);
> +   unsigned int irq = *(unsigned int *)data;
> +   enable_percpu_irq(irq, IRQ_TYPE_NONE);
>  }
>
>  static int
> @@ -440,8 +441,7 @@ armpmu_reserve_hardware(struct arm_pmu *armpmu)
> return err;
> }
>
> -   on_each_cpu(armpmu_enable_percpu_irq, (void *)(long)irq, 1);
> -   cpumask_setall(&armpmu->active_irqs);
> +   on_each_cpu(armpmu_enable_percpu_irq, &irq, 1);
> } else {
> for (i = 0; i < irqs; ++i) {
> err = 0;

Acked-by: Vinayak Kale 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] fix printk output

[Sergei Ianovich]

On Tue, 2013-12-10 at 15:59 +1030, Rusty Russell wrote:
> Sergei Ianovich  writes:
> Hmm, the copy here is gratuitous.  Using current->comm is safe, just
> possibly ambigious if someone is changing the task name at the same time.
> 
> And we really want this one line anyway:
> 
>   printk(KERN_WARNING
>  "%s: waiting module removal not supported: please 
> upgrade\n",
> current->comm);

I would put tool's name in the end for clarity. Message comes from the
kernel and the kernel recommends to upgrade the tool. "%s: ..." could
make the impression that the tool recommends to upgrade the kernel.

> BTW, did you actually hit this?

# modprobe usb_storage
[  600.807274] usbcore: registered new interface driver usb-storage
# modprobe -r usb_storage
[  604.216318] waiting module removal not supported: please upgrade[
604.222164] usbcore: deregistering interface driver usb-storage
# modprobe -V
kmod version 9

I am using the latest kmod package from emdebian unstable-grip.

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

Re: [PATCH 1/2] ARM: dts: bcm281xx: Add i2c busses

[Christian Daudt]

On Fri, Dec 6, 2013 at 3:45 PM, Tim Kryger  wrote:
> Add the DTS nodes for all the i2c busses in the SoC.
>
> Signed-off-by: Tim Kryger 
> Reviewed-by: Christian Daudt 
> Reviewed-by: Matt Porter 
> Reviewed-by: Markus Mayer 
> ---
>  arch/arm/boot/dts/bcm11351.dtsi | 40 
>  1 file changed, 40 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
> index 1246885..4bfd7e3 100644
> --- a/arch/arm/boot/dts/bcm11351.dtsi
> +++ b/arch/arm/boot/dts/bcm11351.dtsi
> @@ -146,6 +146,46 @@
> status = "disabled";
> };
>
> +   i2c@3e016000 {
> +   compatible = "brcm,bcm11351-i2c", "brcm,kona-i2c";
> +   reg = <0x3e016000 0x80>;
> +   interrupts = ;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   clocks = <&bsc1_clk>;
> +   status = "disabled";
> +   };
> +
> +   i2c@3e017000 {
> +   compatible = "brcm,bcm11351-i2c", "brcm,kona-i2c";
> +   reg = <0x3e017000 0x80>;
> +   interrupts = ;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   clocks = <&bsc2_clk>;
> +   status = "disabled";
> +   };
> +
> +   i2c@3e018000 {
> +   compatible = "brcm,bcm11351-i2c", "brcm,kona-i2c";
> +   reg = <0x3e018000 0x80>;
> +   interrupts = ;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   clocks = <&bsc3_clk>;
> +   status = "disabled";
> +   };
> +
> +   i2c@3500d000 {
> +   compatible = "brcm,bcm11351-i2c", "brcm,kona-i2c";
> +   reg = <0x3500d000 0x80>;
> +   interrupts = ;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   clocks = <&pmu_bsc_clk>;
> +   status = "disabled";
> +   };
> +
> clocks {
> bsc1_clk: bsc1 {
> compatible = "fixed-clock";
> --
> 1.8.0.1
>
Applied to armsoc/for-3.14/dt
 thanks,
  csd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: questions of cpuidle

[Daniel Lezcano]

On 12/10/2013 07:33 AM, Alex Shi wrote:

On 12/09/2013 10:17 PM, Daniel Lezcano wrote:


Concerning the wake up of the cpu: the cpu disabled the irq and
goes to sleep, it is up to the firmware to wake up the cpu when an
interrupt occurs. It will exits its sleep state, call
clock_events_notify(EXIT), by this way re-switching to the local
timer, and then re-enabling the local interrupt which leads to the
interrupt handler.


Thanks a lots for excellent article and detailed explains!

So, if the firmware is in response to wake up cpu. that means there
is a unit which control the firmware and it can not be power down.


Correct.


Do you know which unit running the firmware to wake up deep idle
CPU.


That depends on the SoC implementation.

Some SoC have a "Power Management Unit". The PMU has several idle states
defined, each of them are described in the technical reference manual
(TRM) with the wake up sources.

Some SoC don't have any PMU and the idle states are very few, keeping
most of the logic on.

Some other SoC hide the PMU behind PSCI calls.


And does the wake up pass via GIC to CPU? If so, does the GIC need
keep awake when all cpu idle? If not, how the firmware give the
interrupt to CPU? And I am wondering if the deep idle cpu voltage get
to near 0. How the cpu get the interrupt signal?


If a deep idle state powers down the GIC, it is up to the PMU to proxy
the interrupts. When an interrupt occurs, the PMU powers up the logic,
including the GIC. The notifier call chain with cpu_suspend / cpu_resume
will save and restore the GIC registers.

But this is hardware specific and will depend on how the PMU is
implemented and how far it goes in the power management.

You have a good example in the drivers/cpuidle/cpuidle-ux500.c to
understand with the comments how the interrupts are handled through the
power management unit.

In the Xillinx documentation available on the web [1], the chapter 24.4
gives the information about one kind of PMU.

I believe the mechanism is pretty similar on all the hardware but it is
obfuscated by a generic power instruction like mwait.

  -- Daniel

[1]
http://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf



There are some more informations in the wiki page [1].

-- Daniel

[1]
https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/WakeUpSources









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

Follow Linaro:   Facebook |
 Twitter |
 Blog

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

Re: [PATCH] devtmpfs: Calling delete_path() only when necessary

[Fengguang Wu]

> Hi, Fengguang
> Can you help to add this patch to your test systems?
> It's a one-line change, you can find the patch at
> https://patchwork.kernel.org/patch/3192361/

Hi Axel,

Do you have a public git tree? If not, I'd like to take this chance to
encourage you to setup one. The best work flow is to create a branch,
apply the patch and tell me the git URL and branch name to test.

Thanks,
Fengguang
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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/3] iommu/fsl_pamu: Use dev_is_pci() to check whether it is pci device

[varun.se...@freescale.com]

> -Original Message-
> From: iommu-boun...@lists.linux-foundation.org [mailto:iommu-
> boun...@lists.linux-foundation.org] On Behalf Of Yijing Wang
> Sent: Thursday, December 05, 2013 5:13 PM
> To: Alex Williamson; Joerg Roedel
> Cc: io...@lists.linux-foundation.org; linux-kernel@vger.kernel.org;
> Hanjun Guo
> Subject: [PATCH 2/3] iommu/fsl_pamu: Use dev_is_pci() to check whether it
> is pci device
> 
> Use PCI standard marco dev_is_pci() instead of directly compare
> pci_bus_type to check whether it is pci device.
> 
> Signed-off-by: Yijing Wang 
> ---
>  drivers/iommu/fsl_pamu_domain.c |6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/iommu/fsl_pamu_domain.c
> b/drivers/iommu/fsl_pamu_domain.c index c857c30..93072ba 100644
> --- a/drivers/iommu/fsl_pamu_domain.c
> +++ b/drivers/iommu/fsl_pamu_domain.c
> @@ -691,7 +691,7 @@ static int fsl_pamu_attach_device(struct iommu_domain
> *domain,
>* Use LIODN of the PCI controller while attaching a
>* PCI device.
>*/
> - if (dev->bus == &pci_bus_type) {
> + if (dev_is_pci(dev)) {
>   pdev = to_pci_dev(dev);
>   pci_ctl = pci_bus_to_host(pdev->bus);
>   /*
> @@ -729,7 +729,7 @@ static void fsl_pamu_detach_device(struct
> iommu_domain *domain,
>* Use LIODN of the PCI controller while detaching a
>* PCI device.
>*/
> - if (dev->bus == &pci_bus_type) {
> + if (dev_is_pci(dev)) {
>   pdev = to_pci_dev(dev);
>   pci_ctl = pci_bus_to_host(pdev->bus);
>   /*
> @@ -1056,7 +1056,7 @@ static int fsl_pamu_add_device(struct device *dev)
>* For platform devices we allocate a separate group for
>* each of the devices.
>*/
> - if (dev->bus == &pci_bus_type) {
> + if (dev_is_pci(dev)) {
>   pdev = to_pci_dev(dev);
>   /* Don't create device groups for virtual PCI bridges */
>   if (pdev->subordinate)
> --
> 1.7.1
Acked-by: Varun Sethi 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 1/8] ARM: dts: Declare clocks as fixed on bcm11351

[Christian Daudt]

Applied to armsoc/for-3.14/dt

 thanks,
   csd


On Thu, Dec 5, 2013 at 11:20 AM, Tim Kryger  wrote:
> Declare clocks that are enabled and configured by bootloaders as fixed
> rate clocks in the DTS such that device drivers may use standard clock
> function calls.
>
> Signed-off-by: Tim Kryger 
> Reviewed-by: Markus Mayer 
> Reviewed-by: Matt Porter 
> ---
>  arch/arm/boot/dts/bcm11351.dtsi | 97 
> +
>  1 file changed, 97 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi
> index b0c0610..eca6fbc 100644
> --- a/arch/arm/boot/dts/bcm11351.dtsi
> +++ b/arch/arm/boot/dts/bcm11351.dtsi
> @@ -142,4 +142,101 @@
> status = "disabled";
> };
>
> +   clocks {
> +   bsc1_clk: bsc1 {
> +   compatible = "fixed-clock";
> +   clock-frequency = <1300>;
> +   #clock-cells = <0>;
> +   };
> +
> +   bsc2_clk: bsc2 {
> +   compatible = "fixed-clock";
> +   clock-frequency = <1300>;
> +   #clock-cells = <0>;
> +   };
> +
> +   bsc3_clk: bsc3 {
> +   compatible = "fixed-clock";
> +   clock-frequency = <1300>;
> +   #clock-cells = <0>;
> +   };
> +
> +   pmu_bsc_clk: pmu_bsc {
> +   compatible = "fixed-clock";
> +   clock-frequency = <1300>;
> +   #clock-cells = <0>;
> +   };
> +
> +   hub_timer_clk: hub_timer {
> +   compatible = "fixed-clock";
> +   clock-frequency = <32768>;
> +   #clock-cells = <0>;
> +   };
> +
> +   pwm_clk: pwm {
> +   compatible = "fixed-clock";
> +   clock-frequency = <2600>;
> +   #clock-cells = <0>;
> +   };
> +
> +   sdio1_clk: sdio1 {
> +   compatible = "fixed-clock";
> +   clock-frequency = <4800>;
> +   #clock-cells = <0>;
> +   };
> +
> +   sdio2_clk: sdio2 {
> +   compatible = "fixed-clock";
> +   clock-frequency = <4800>;
> +   #clock-cells = <0>;
> +   };
> +
> +   sdio3_clk: sdio3 {
> +   compatible = "fixed-clock";
> +   clock-frequency = <4800>;
> +   #clock-cells = <0>;
> +   };
> +
> +   sdio4_clk: sdio4 {
> +   compatible = "fixed-clock";
> +   clock-frequency = <4800>;
> +   #clock-cells = <0>;
> +   };
> +
> +   tmon_1m_clk: tmon_1m {
> +   compatible = "fixed-clock";
> +   clock-frequency = <100>;
> +   #clock-cells = <0>;
> +   };
> +
> +   uartb_clk: uartb {
> +   compatible = "fixed-clock";
> +   clock-frequency = <1300>;
> +   #clock-cells = <0>;
> +   };
> +
> +   uartb2_clk: uartb2 {
> +   compatible = "fixed-clock";
> +   clock-frequency = <1300>;
> +   #clock-cells = <0>;
> +   };
> +
> +   uartb3_clk: uartb3 {
> +   compatible = "fixed-clock";
> +   clock-frequency = <1300>;
> +   #clock-cells = <0>;
> +   };
> +
> +   uartb4_clk: uartb4 {
> +   compatible = "fixed-clock";
> +   clock-frequency = <1300>;
> +   #clock-cells = <0>;
> +   };
> +
> +   usb_otg_ahb_clk: usb_otg_ahb {
> +   compatible = "fixed-clock";
> +   clock-frequency = <5200>;
> +   #clock-cells = <0>;
> +   };
> +   };
>  };
> --
> 1.8.0.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: UBIFS recovery taking too long

[Adrian Hunter]

On 09/12/13 23:30, Shuah Khan wrote:
> Adding ubifs maintainers.
> 
> -- Shuah
> 
> On Mon, Dec 9, 2013 at 1:53 PM, David Mosberger-Tang
>  wrote:
>> I've had no luck getting any response from the linux-mtd mailing list
>> regarding the issue reported below.
>> I think it is a very serious issue since it can easily render an
>> embedded system unusable.
>>
>>   --david
>>
>> -- Forwarded message --
>> From: David Mosberger-Tang 
>> Date: Thu, Nov 7, 2013 at 11:44 AM
>> Subject: UBIFS recovery taking too long
>> To: "linux-...@lists.infradead.org" 
>>
>>
>> We recently encountered a strange issue where UBIFS recovery is
>> suddenly taking a lot longer than usual (v3.7-based kernel).  In our
>> case, recovery took about 30 seconds.  This caused a serious problem
>> because our watchdog timer was set to 15 seconds, effectively
>> rendering the devices unbootable.
>>
>> Does anybody know what triggers this slow recovery mode?  Also, how
>> can we calculate a worst-case recovery time for a given flash
>> chip-size.

Slowness is probably caused by trying to make free space.  Was the file
system very full?  A smaller journal might help.

Probably the only way to determine worst-case recovery time is to test it.
Worst case conditions are likely to be a full journal and a nearly full file
system.

Ideally you want to capture a file system image that exhibits the slow
behaviour, then you can enable debug messages and see what it is doing.

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

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

Re: [PATCH v2] fix printk output

[Rusty Russell]

Sergei Ianovich  writes:
> Signed-off-by: Sergei Ianovich 
> CC: Hannes Frederic Sowa 
> ---
>  Changes v1..v2
>  * 1-for-1 match between source and output lines
>  * clarify warning
>  * print tool name to avoid confusion with what to upgrade

Hmm, the copy here is gratuitous.  Using current->comm is safe, just
possibly ambigious if someone is changing the task name at the same time.

And we really want this one line anyway:

printk(KERN_WARNING
   "%s: waiting module removal not supported: please 
upgrade\n",
current->comm);

BTW, did you actually hit this?

Thanks,
Rusty.

>  kernel/module.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/module.c b/kernel/module.c
> index f5a3b1e..0e627e7 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -816,8 +816,10 @@ SYSCALL_DEFINE2(delete_module, const char __user *, 
> name_user,
>   name[MODULE_NAME_LEN-1] = '\0';
>  
>   if (!(flags & O_NONBLOCK)) {
> + char tool[TASK_COMM_LEN];
>   printk(KERN_WARNING
> -"waiting module removal not supported: please upgrade");
> +"waiting module removal no longer supported\n"
> +"please upgrade %s\n", get_task_comm(tool, current));
>   }
>  
>   if (mutex_lock_interruptible(&module_mutex) != 0)
> -- 
> 1.8.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kernel BUG at kernel/kallsyms.c:222!

[Rusty Russell]

Ming Lei  writes:

> Hi Axel,
>
> I am fine to resend it to RMK's patch system, but I am not sure
> if Russell would like to host it.
>
> Maybe it is better to push it via Rusty's tree since the change is only
> on scripts/, and it doesn't depend on the 1st one.
>
> Rusty, could you pick up the patch with title of
> "scripts/link-vmlinux.sh: only filter kernel symbols for arm"?

OK, and I added the correct Fixes: line so the stable people can track
it properly:

Cc: 
Cc: Rusty Russell 
Fixes: f6537f2f0eba4eba3354e48dbe3047db6d8b6254
Singed-off-by: Ming Lei 
Signed-off-by: Rusty Russell 

BTW, you misspelled Signed-off-by :)

Applied,
Rusty.


>
> Thanks,
> --
> Ming Lei
>
> On Mon, Dec 2, 2013 at 9:57 AM, Axel Lin  wrote:
>> 2013/11/13 Ming Lei :
>>> Hi Axel,
>>>
>>> On Wed, Nov 13, 2013 at 5:58 PM, Axel Lin  wrote:

 Hi Ming,
 You missed "; then" in the end of if statement in your patch.

 So I got below error with your patch:
 scripts/link-vmlinux.sh: line 87: syntax error near unexpected token `fi'
 make: *** [vmlinuxclean] Error 2
>>>
>>> Thanks for your test, and I have fixed it and post a formal one for merge,
>>> and you can find these two patches on arm list, but forget to Cc you, sorry
>>> for that.
>>
>> Hi Ming,
>> Both your patch and Jonathan's patch are still not in linux-next.
>> Any chance to resend the patchs to RMK's patch system?
>>
>> Thanks,
>> Axel
>
>
>
> -- 
> Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH V3 1/2] pinctrl: tegra: Add devicetree binding document for Tegra124

[Laxman Dewangan]

This device tree binding document describes the Tegra124 pincontrol
DT bindings. This document lists all valid properties, names, mux
options of Tegra124 pins.

Signed-off-by: Laxman Dewangan 
Acked-by: Stephen Warren 
---
Changes from V1: 
- Referred the dt-binding header file on describing the nodes.

Changes from V2:
- Rewording reg properties.
- drop drv_type as it is not applicable.

 .../bindings/pinctrl/nvidia,tegra124-pinmux.txt|  144 
 1 files changed, 144 insertions(+), 0 deletions(-)
 create mode 100644 
Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.txt

diff --git 
a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.txt 
b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.txt
new file mode 100644
index 000..6464bf7
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.txt
@@ -0,0 +1,144 @@
+NVIDIA Tegra124 pinmux controller
+
+The Tegra124 pinctrl binding is very similar to the Tegra20 and Tegra30
+pinctrl binding, as described in nvidia,tegra20-pinmux.txt and
+nvidia,tegra30-pinmux.txt. In fact, this document assumes that binding as
+a baseline, and only documents the differences between the two bindings.
+
+Required properties:
+- compatible: "nvidia,tegra124-pinmux"
+- reg: Should contain a list of base address and size pairs for:
+-- first entry - the drive strength and pad control registers.
+-- second entry - the pinmux registers
+
+Tegra124 adds the following optional properties for pin configuration subnodes.
+The macros for options are defined in the
+   include/dt-binding/pinctrl/pinctrl-tegra.h.
+- nvidia,enable-input: Integer. Enable the pin's input path.
+   enable :TEGRA_PIN_ENABLE0 and
+   disable or output only: TEGRA_PIN_DISABLE.
+- nvidia,open-drain: Integer.
+   enable: TEGRA_PIN_ENABLE.
+   disable: TEGRA_PIN_DISABLE.
+- nvidia,lock: Integer. Lock the pin configuration against further changes
+until reset.
+   enable: TEGRA_PIN_ENABLE.
+   disable: TEGRA_PIN_DISABLE.
+- nvidia,io-reset: Integer. Reset the IO path.
+   enable: TEGRA_PIN_ENABLE.
+   disable: TEGRA_PIN_DISABLE.
+- nvidia,rcv-sel: Integer. Select VIL/VIH receivers.
+   normal: TEGRA_PIN_DISABLE
+   high: TEGRA_PIN_ENABLE
+
+Please refer the Tegra TRM for complete details regarding which groups
+support which functionality.
+
+Valid values for pin and group names are:
+
+  per-pin mux groups:
+
+These all support nvidia,function, nvidia,tristate, nvidia,pull,
+nvidia,enable-input. Some support nvidia,lock nvidia,open-drain,
+nvidia,io-reset and nvidia,rcv-sel.
+
+   ulpi_data0_po1, ulpi_data1_po2, ulpi_data2_po3, ulpi_data3_po4,
+   ulpi_data4_po5, ulpi_data5_po6, ulpi_data6_po7, ulpi_data7_po0,
+   ulpi_clk_py0, ulpi_dir_py1, ulpi_nxt_py2, ulpi_stp_py3, dap3_fs_pp0,
+   dap3_din_pp1, dap3_dout_pp2, dap3_sclk_pp3, pv0, pv1, sdmmc1_clk_pz0,
+   sdmmc1_cmd_pz1, sdmmc1_dat3_py4, sdmmc1_dat2_py5, sdmmc1_dat1_py6,
+   sdmmc1_dat0_py7, clk2_out_pw5, clk2_req_pcc5, hdmi_int_pn7, ddc_scl_pv4,
+   ddc_sda_pv5, uart2_rxd_pc3, uart2_txd_pc2, uart2_rts_n_pj6,
+   uart2_cts_n_pj5, uart3_txd_pw6, uart3_rxd_pw7, uart3_cts_n_pa1,
+   uart3_rts_n_pc0, pu0, pu1, pu2, pu3, pu4, pu5, pu6, gen1_i2c_scl_pc4,
+   gen1_i2c_sda_pc5, dap4_fs_pp4, dap4_din_pp5, dap4_dout_pp6,
+   dap4_sclk_pp7, clk3_out_pee0, clk3_req_pee1, pc7, pi5, pi7, pk0, pk1,
+   pj0, pj2, pk3, pk4, pk2, pi3, pi6, pg0, pg1, pg2, pg3, pg4, pg5, pg6,
+   pg7, ph0, ph1, ph2, ph3, ph4, ph5, ph6, ph7, pj7, pb0, pb1, pk7, pi0,
+   pi1, pi2, pi4, gen2_i2c_scl_pt5, gen2_i2c_sda_pt6, sdmmc4_clk_pcc4,
+   sdmmc4_cmd_pt7, sdmmc4_dat0_paa0, sdmmc4_dat1_paa1, sdmmc4_dat2_paa2,
+   sdmmc4_dat3_paa3, sdmmc4_dat4_paa4, sdmmc4_dat5_paa5, sdmmc4_dat6_paa6,
+   sdmmc4_dat7_paa7, cam_mclk_pcc0, pcc1, pbb0, cam_i2c_scl_pbb1,
+   cam_i2c_sda_pbb2, pbb3, pbb4, pbb5, pbb6, pbb7, pcc2, jtag_rtck,
+   pwr_i2c_scl_pz6, pwr_i2c_sda_pz7, kb_row0_pr0, kb_row1_pr1, kb_row2_pr2,
+   kb_row3_pr3, kb_row4_pr4, kb_row5_pr5, kb_row6_pr6, kb_row7_pr7,
+   kb_row8_ps0, kb_row9_ps1, kb_row10_ps2, kb_row11_ps3, kb_row12_ps4,
+   kb_row13_ps5, kb_row14_ps6, kb_row15_ps7, kb_col0_pq0, kb_col1_pq1,
+   kb_col2_pq2, kb_col3_pq3, kb_col4_pq4, kb_col5_pq5, kb_col6_pq6,
+   kb_col7_pq7, clk_32k_out_pa0, core_pwr_req, cpu_pwr_req, pwr_int_n,
+   clk_32k_in, owr, dap1_fs_pn0, dap1_din_pn1, dap1_dout_pn2,
+   dap1_sclk_pn3, dap_mclk1_req_pee2, dap_mclk1_pw4, spdif_in_pk6,
+   spdif_out_pk5, dap2_fs_pa2, dap2_din_pa4, dap2_dout_pa5, dap2_sclk_pa3,
+   dvfs_pwm_px0, gpio_x1_aud_px1, gpio_x3_aud_px3, dvfs_clk_px2,
+   gpio_x4_aud_px4, gpio_x5_aud_px5, gpio_x6_aud_px6, gpio_x7_aud_px7,
+   sdmmc3_clk_pa6, sdmmc3_cmd_pa7, sdmmc3_dat0_pb7, sdmmc3_dat1_p

[PATCH] scripts/gcc-version.sh: handle CC="gcc -m32"

[Rusty Russell]

Without it we get ugly warnings (though build still succeeds).

$ make -j8 CC="gcc -m32"
In file included from :0:0:
/usr/include/stdc-predef.h:30:26: fatal error: bits/predefs.h: No such file or 
directory
 #include 
  ^
compilation terminated.
In file included from :0:0:
/usr/include/stdc-predef.h:30:26: fatal error: bits/predefs.h: No such file or 
directory
 #include 
  ^
compilation terminated.
/home/rusty/devel/kernel/linux/scripts/gcc-version.sh: line 31: printf: #: 
invalid number
/home/rusty/devel/kernel/linux/scripts/gcc-version.sh: line 31: printf: #: 
invalid number
/bin/sh: 1: [: 0001: unexpected operator
  CHK include/config/kernel.release
  CHK include/generated/uapi/linux/version.h
make[1]: Nothing to be done for `all'.
...

Signed-off-by: Rusty Russell 

diff --git a/scripts/gcc-version.sh b/scripts/gcc-version.sh
index 7f2126df91f2..d48b0cbaf246 100644
--- a/scripts/gcc-version.sh
+++ b/scripts/gcc-version.sh
@@ -14,7 +14,7 @@ if [ "$1" = "-p" ] ; then
shift;
 fi
 
-compiler="$*"
+compiler="$1"
 
 if [ ${#compiler} -eq 0 ]; then
echo "Error: No compiler specified."
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Ignore generated file kernel/x509_certificate_list

[Rusty Russell]

$ git status
# On branch pending-rebases
# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
#   kernel/x509_certificate_list
nothing added to commit but untracked files present (use "git add" to track)
$ 

Cc: David Howells 
Signed-off-by: Rusty Russell 

diff --git a/kernel/.gitignore b/kernel/.gitignore
index b3097bde4e9c..790d83c7d160 100644
--- a/kernel/.gitignore
+++ b/kernel/.gitignore
@@ -5,3 +5,4 @@ config_data.h
 config_data.gz
 timeconst.h
 hz.bc
+x509_certificate_list
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 12/12] sched/numa: drop local 'ret' in task_numa_migrate()

[Naoya Horiguchi]

On Sun, Dec 08, 2013 at 02:14:53PM +0800, Wanpeng Li wrote:
> task_numa_migrate() has two locals called "ret". Fix it all up.
> 
> Signed-off-by: Wanpeng Li 

Reviewed-by: Naoya Horiguchi 

Thanks!
Naoya

> ---
>  kernel/sched/fair.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index df8b677..3159ca7 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -1257,7 +1257,7 @@ static int task_numa_migrate(struct task_struct *p)
>   p->numa_scan_period = task_scan_min(p);
>  
>   if (env.best_task == NULL) {
> - int ret = migrate_task_to(p, env.best_cpu);
> + ret = migrate_task_to(p, env.best_cpu);
>   return ret;
>   }
>  
> -- 
> 1.7.5.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 19/39] mtd: denali: remove DEFINE_PCI_DEVICE_TABLE macro

[Brian Norris]

On Tue, Dec 03, 2013 at 08:18:28AM +0900, Jingoo Han wrote:
> Don't use DEFINE_PCI_DEVICE_TABLE macro, because this macro
> is not preferred.
> 
> Signed-off-by: Jingoo Han 

Pushed to l2-mtd.git.

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

Re: [PATCH v3 11/12] sched/numa: drop unnecessary variable in task_weight

[Naoya Horiguchi]

On Sun, Dec 08, 2013 at 02:14:52PM +0800, Wanpeng Li wrote:
> Drop unnecessary total_faults variable in function task_weight to unify
> task_weight and group_weight.
> 
> Signed-off-by: Wanpeng Li 

Reviewed-by: Naoya Horiguchi 

> ---
>  kernel/sched/fair.c |   11 ++-
>  1 files changed, 2 insertions(+), 9 deletions(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 942e67b..df8b677 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -947,17 +947,10 @@ static inline unsigned long group_faults(struct 
> task_struct *p, int nid)
>   */
>  static inline unsigned long task_weight(struct task_struct *p, int nid)
>  {
> - unsigned long total_faults;
> -
> - if (!p->numa_faults)
> - return 0;
> -
> - total_faults = p->total_numa_faults;
> -
> - if (!total_faults)
> + if (!p->numa_faults || !p->total_numa_faults)
>   return 0;
>  
> - return 1000 * task_faults(p, nid) / total_faults;
> + return 1000 * task_faults(p, nid) / p->total_numa_faults;
>  }
>  
>  static inline unsigned long group_weight(struct task_struct *p, int nid)
> -- 
> 1.7.5.4
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm/slab.c: check pointer slabp before using it in alloc_slabmgmt()

[Ethan Zhao]

Christoph,
Found in the latest stable release V3.12.3,  yes, changed in
3.12.4. not needed for later release anymore.

Thanks,
Ethan


On Tue, Dec 10, 2013 at 12:11 AM, Christoph Lameter  wrote:
> On Sun, 8 Dec 2013, ethan.zhao wrote:
>
>> Move the NULL check of slabp to the right place before refer its memeber in
>> function alloc_slabmgmt().
>
> I am having trouble to find the code you are modifying. Which kernel
> release is this? The code you are referring to has been rewritten in the
> meantime or this is some other code basis.
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] ARM: dts: bcm28155-ap: Enable all the i2c busses

[Christian Daudt]

Applied to armsoc/for-3.14/dt
 thanks,
   csd


On Fri, Dec 6, 2013 at 3:45 PM, Tim Kryger  wrote:
> Enable all available i2c busses.
>
> Signed-off-by: Tim Kryger 
> Reviewed-by: Christian Daudt 
> Reviewed-by: Matt Porter 
> Reviewed-by: Markus Mayer 
> ---
>  arch/arm/boot/dts/bcm28155-ap.dts | 20 
>  1 file changed, 20 insertions(+)
>
> diff --git a/arch/arm/boot/dts/bcm28155-ap.dts 
> b/arch/arm/boot/dts/bcm28155-ap.dts
> index 08e47c2..bab302d 100644
> --- a/arch/arm/boot/dts/bcm28155-ap.dts
> +++ b/arch/arm/boot/dts/bcm28155-ap.dts
> @@ -27,6 +27,26 @@
> status = "okay";
> };
>
> +   i2c@3e016000 {
> +   status="okay";
> +   clock-frequency = <40>;
> +   };
> +
> +   i2c@3e017000 {
> +   status="okay";
> +   clock-frequency = <40>;
> +   };
> +
> +   i2c@3e018000 {
> +   status="okay";
> +   clock-frequency = <40>;
> +   };
> +
> +   i2c@3500d000 {
> +   status="okay";
> +   clock-frequency = <40>;
> +   };
> +
> sdio1: sdio@3f18 {
> max-frequency = <4800>;
> status = "okay";
> --
> 1.8.0.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 10/12] sched/numa: fix record hinting faults check

[Naoya Horiguchi]

On Sun, Dec 08, 2013 at 02:14:51PM +0800, Wanpeng Li wrote:
> Adjust numa_scan_period in task_numa_placement, depending on how much useful
> work the numa code can do. The local faults and remote faults should be used
> to check if there is record hinting faults instead of local faults and shared
> faults. This patch fix it.
> 
> Signed-off-by: Wanpeng Li 

Looks good to me.

Reviewed-by: Naoya Horiguchi 

> ---
>  kernel/sched/fair.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index b077f1b3..942e67b 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -1322,7 +1322,7 @@ static void update_task_scan_period(struct task_struct 
> *p,
>* completely idle or all activity is areas that are not of interest
>* to automatic numa balancing. Scan slower
>*/
> - if (local + shared == 0) {
> + if (local + remote == 0) {
>   p->numa_scan_period = min(p->numa_scan_period_max,
>   p->numa_scan_period << 1);
>  
> -- 
> 1.7.5.4
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org";> em...@kvack.org 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] r_du_lvdsenc.c : Check return value of devm_ioremap_resource with IS_ERR

[Ethan Zhao]

Laurent,

Next time I scan the NULL check, if hit your driver again, I will resend it.

Thanks,
Ethan

On Tue, Dec 10, 2013 at 10:24 AM, Laurent Pinchart
 wrote:
> Hi Ethan,
>
> Thank you for the patch.
>
> On Sunday 08 December 2013 10:41:46 ethan.zhao wrote:
>> function devm_ioremap_resource() doesn't return NULL, should check its
>> return value with helper IS_ERR().
>>
>> Signed-off-by: ethan.zhao 
>
> This issue has already been addressed by a patch sent to the dri-devel mailing
> list by Wei Yongjun (https://lkml.org/lkml/2013/8/22/637).
>
> I've asked for a v2 to be submitted but haven't received any reply. I'll fix
> the problem myself and send the patch now.
>
>> ---
>>  drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
>> b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c index a0f6a17..93190ab 100644
>> --- a/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
>> +++ b/drivers/gpu/drm/rcar-du/rcar_du_lvdsenc.c
>> @@ -151,7 +151,7 @@ static int rcar_du_lvdsenc_get_resources(struct
>> rcar_du_lvdsenc *lvds, }
>>
>>   lvds->mmio = devm_ioremap_resource(&pdev->dev, mem);
>> - if (lvds->mmio == NULL) {
>> + if (IS_ERR(lvds->mmio)) {
>>   dev_err(&pdev->dev, "failed to remap memory resource for %s\n",
>>   name);
>>   return -ENOMEM;
>
> --
> Regards,
>
> Laurent Pinchart
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net-tg3: Initialize REG_BASE_ADDR at PCI config offset 120 to 0

[Michael Chan]

On Mon, 2013-12-09 at 13:07 -0800, Michael Chan wrote: 
> On Tue, 2013-12-10 at 00:18 +0300, Sergei Shtylyov wrote: 
> > >We had crashes when the PCI config space got scanned via
> > > /sys/devices/pci/../config.
> > 
> > > I agree that this fix will not help if the scan happens before the tg3
> > > driver gets loaded.
> > 
> > Then perhaps a better place for such fixup would be a PCI quirk?
> > 
> Yes, I agree.  Thanks.
> 

On second thought, I think your original patch should be sufficient and
we don't need to add the PCI quirk to cover so many devices.  The reason
is that indirect access needs to be explicitly enabled in the
MISC_HOST_CTRL (0x68) register.  The default value for register 0x68
should have indirect access disabled.

Nat, does this match what you're seeing?  Did you ever see any system
crash before tg3 loads?

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

Re: [PATCH v3 07/15] KVM: MMU: introduce nulls desc

[Xiao Guangrong]

On 12/06/2013 08:22 AM, Marcelo Tosatti wrote:
> On Thu, Dec 05, 2013 at 11:30:27PM +0800, Xiao Guangrong wrote:
>> In some cases, the lockless walker will do endless-walking on desc and
>> without rewalk, consider this case:
>>
>> there are two descs: desc1 and desc2 who is pointed by desc1->next：
>> desc1->next = desc2.
>>
>> CPU 0
>> CPU 1
>>
>> lockless walk on desc1
>>  deleting 
>> desc1 from the rmap
>> lockless walk on desc2 (desc1->next)
>> delete desc2 
>> from the rmap
>> add desc1
>> add desc2, 
>> then desc2->next = desc1
>>
>> lockless walk on desc1
>>delete desc2
>>delete desc1
>>add desc2
>>add desc1; 
>> the desc1->next = desc2
>> lockless walk on desc2
>>
>> ……
>>
>> Then, the walker is endlessly walking on desc1 and desc2 without any rewalk.
> 
> The counter can be local to the walker. If its more than maximum rmap
> size, break.
> 
> (but still, please consider carefully whether lockless list walking is
> really necessary or can be avoided).

Yep, Marcelo, you're right.

After thinking more, i do not have any idea to simplify this. Your approach
(lockless on the first level) seems a better solution. Will do it based on that
ways.

Thanks!


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

Re: [PATCH] net: sk == 0xffffffff fix - not for commit

[Andrzej Pietrasiewicz]

W dniu 09.12.2013 16:31, Eric Dumazet pisze:

On Mon, 2013-12-09 at 12:47 +0100, Andrzej Pietrasiewicz wrote:

NOT FOR COMMITTING TO MAINLINE.

With g_ether loaded the sk occasionally becomes 0x.
It happens usually after transferring few hundreds of kilobytes to few
tens of megabytes. If sk is 0x then dereferencing it causes
kernel panic.

This is a *workaround*. I don't know enough net code to understand the core
of the problem. However, with this patch applied the problems are gone,
or at least pushed farther away.


Is it happening on SMP or UP ?


UP build, S5PC110



Crash should happen earlier in __inet_lookup_established()





AP
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 3/3] perf script: Improve srcline display for BTS

[Adrian Hunter]

On 10/12/13 09:04, Adrian Hunter wrote:
> On 09/12/13 20:04, Arnaldo Carvalho de Melo wrote:
>> Em Fri, Dec 06, 2013 at 09:42:58AM +0200, Adrian Hunter escreveu:
>>> Change the order of the output to put the srcline last.
>>> e.g. old format:
>>
>> Can you please always provide the command line used, so that people can
>> quickly reproduce your results, before and after your changes?
> 
> OK
> 
> perf record -e branches:u -c 1 -d ls
> 
> perf script -fip,sym,symoff,addr,srcline

Oops missed dso.  That should be:

perf script -fip,sym,symoff,dso,addr,srcline

> 
>>
>> - Arnaldo
>>  
>>>   4028fc main+0x2c (/bin/ls)
>>>   /build/buildd/coreutils-8.20/src/ls.c:1269 =>   40d8a0 
>>> set_program_name+0x0 (/bin/ls)
>>>
>>> new format:
>>>
>>>   4028fc main+0x2c (/bin/ls) =>   40d8a0 
>>> set_program_name+0x0 (/bin/ls)
>>>   /build/buildd/coreutils-8.20/src/ls.c:1269
>>>
>>> Signed-off-by: Adrian Hunter 
>>> ---
>>>  tools/perf/builtin-script.c | 20 +++-
>>>  1 file changed, 15 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
>>> index 7a571fb..8997b69 100644
>>> --- a/tools/perf/builtin-script.c
>>> +++ b/tools/perf/builtin-script.c
>>> @@ -428,15 +428,22 @@ static void print_sample_bts(union perf_event *event,
>>>  struct addr_location *al)
>>>  {
>>> struct perf_event_attr *attr = &evsel->attr;
>>> +   bool print_srcline_last = false;
>>>  
>>> /* print branch_from information */
>>> if (PRINT_FIELD(IP)) {
>>> -   if (!symbol_conf.use_callchain)
>>> -   printf(" ");
>>> -   else
>>> +   unsigned int print_opts = output[attr->type].print_ip_opts;
>>> +
>>> +   if (symbol_conf.use_callchain && sample->callchain) {
>>> printf("\n");
>>> -   perf_evsel__print_ip(evsel, sample, machine, al,
>>> -output[attr->type].print_ip_opts,
>>> +   } else {
>>> +   printf(" ");
>>> +   if (print_opts & PRINT_IP_OPT_SRCLINE) {
>>> +   print_srcline_last = true;
>>> +   print_opts &= ~PRINT_IP_OPT_SRCLINE;
>>> +   }
>>> +   }
>>> +   perf_evsel__print_ip(evsel, sample, machine, al, print_opts,
>>>  PERF_MAX_STACK_DEPTH);
>>> }
>>>  
>>> @@ -448,6 +455,9 @@ static void print_sample_bts(union perf_event *event,
>>>  !output[attr->type].user_set))
>>> print_sample_addr(event, sample, machine, thread, attr);
>>>  
>>> +   if (print_srcline_last)
>>> +   map__fprintf_srcline(al->map, al->addr, "\n  ", stdout);
>>> +
>>> printf("\n");
>>>  }
>>>  
>>> -- 
>>> 1.7.11.7
>>
>>
> 
> 
> 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 3/3] perf script: Improve srcline display for BTS

[Adrian Hunter]

On 09/12/13 20:04, Arnaldo Carvalho de Melo wrote:
> Em Fri, Dec 06, 2013 at 09:42:58AM +0200, Adrian Hunter escreveu:
>> Change the order of the output to put the srcline last.
>> e.g. old format:
> 
> Can you please always provide the command line used, so that people can
> quickly reproduce your results, before and after your changes?

OK

perf record -e branches:u -c 1 -d ls

perf script -fip,sym,symoff,addr,srcline

> 
> - Arnaldo
>  
>>   4028fc main+0x2c (/bin/ls)
>>   /build/buildd/coreutils-8.20/src/ls.c:1269 =>   40d8a0 
>> set_program_name+0x0 (/bin/ls)
>>
>> new format:
>>
>>   4028fc main+0x2c (/bin/ls) =>   40d8a0 
>> set_program_name+0x0 (/bin/ls)
>>   /build/buildd/coreutils-8.20/src/ls.c:1269
>>
>> Signed-off-by: Adrian Hunter 
>> ---
>>  tools/perf/builtin-script.c | 20 +++-
>>  1 file changed, 15 insertions(+), 5 deletions(-)
>>
>> diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
>> index 7a571fb..8997b69 100644
>> --- a/tools/perf/builtin-script.c
>> +++ b/tools/perf/builtin-script.c
>> @@ -428,15 +428,22 @@ static void print_sample_bts(union perf_event *event,
>>   struct addr_location *al)
>>  {
>>  struct perf_event_attr *attr = &evsel->attr;
>> +bool print_srcline_last = false;
>>  
>>  /* print branch_from information */
>>  if (PRINT_FIELD(IP)) {
>> -if (!symbol_conf.use_callchain)
>> -printf(" ");
>> -else
>> +unsigned int print_opts = output[attr->type].print_ip_opts;
>> +
>> +if (symbol_conf.use_callchain && sample->callchain) {
>>  printf("\n");
>> -perf_evsel__print_ip(evsel, sample, machine, al,
>> - output[attr->type].print_ip_opts,
>> +} else {
>> +printf(" ");
>> +if (print_opts & PRINT_IP_OPT_SRCLINE) {
>> +print_srcline_last = true;
>> +print_opts &= ~PRINT_IP_OPT_SRCLINE;
>> +}
>> +}
>> +perf_evsel__print_ip(evsel, sample, machine, al, print_opts,
>>   PERF_MAX_STACK_DEPTH);
>>  }
>>  
>> @@ -448,6 +455,9 @@ static void print_sample_bts(union perf_event *event,
>>   !output[attr->type].user_set))
>>  print_sample_addr(event, sample, machine, thread, attr);
>>  
>> +if (print_srcline_last)
>> +map__fprintf_srcline(al->map, al->addr, "\n  ", stdout);
>> +
>>  printf("\n");
>>  }
>>  
>> -- 
>> 1.7.11.7
> 
> 

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

[PATCH v4 2/5] PCI: Don't use 4G bus address directly in resource allocation

[Yinghai Lu]

Current we are using PCIBIOS_MAX_MEM_32 (4G limit) directly in the
pci_bus_alloc_resource to make sure that don't allocate too high
pref 64bit above 4G in the system that does not support that.

That is not right, as allocate_resource() should take resource limit.

Add pci_clip_resource() and use it check the pci bus address limit.

At last remove PCIBIOS_MAX_MEM_32.

Signed-off-by: Yinghai Lu 
---
 arch/x86/include/asm/pci.h |  1 -
 drivers/pci/bus.c  | 41 ++---
 include/linux/pci.h|  4 
 3 files changed, 34 insertions(+), 12 deletions(-)

diff --git a/arch/x86/include/asm/pci.h b/arch/x86/include/asm/pci.h
index 947b5c4..122c299 100644
--- a/arch/x86/include/asm/pci.h
+++ b/arch/x86/include/asm/pci.h
@@ -125,7 +125,6 @@ int setup_msi_irq(struct pci_dev *dev, struct msi_desc 
*msidesc,
 
 /* generic pci stuff */
 #include 
-#define PCIBIOS_MAX_MEM_32 0x
 
 #ifdef CONFIG_NUMA
 /* Returns the node based on pci bus */
diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
index fc1b740..3ad4fd9 100644
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -98,6 +98,25 @@ void pci_bus_remove_resources(struct pci_bus *bus)
}
 }
 
+static struct pci_bus_region pci_mem_32 = {0, 0x};
+
+static void pci_clip_resource(struct resource *res, struct pci_bus *bus,
+ struct pci_bus_region *region)
+{
+   struct pci_bus_region r;
+
+   pcibios_resource_to_bus(bus, &r, res);
+   if (r.start < region->start)
+   r.start = region->start;
+   if (r.end > region->end)
+   r.end = region->end;
+
+   if (r.end < r.start)
+   res->end = res->start - 1;
+   else
+   pcibios_bus_to_resource(bus, res, &r);
+}
+
 /**
  * pci_bus_alloc_resource - allocate a resource from a parent bus
  * @bus: PCI bus
@@ -125,15 +144,12 @@ pci_bus_alloc_resource(struct pci_bus *bus, struct 
resource *res,
 {
int i, ret = -ENOMEM;
struct resource *r;
-   resource_size_t max = -1;
 
type_mask |= IORESOURCE_IO | IORESOURCE_MEM;
 
-   /* don't allocate too high if the pref mem doesn't support 64bit*/
-   if (!(res->flags & IORESOURCE_MEM_64))
-   max = PCIBIOS_MAX_MEM_32;
-
pci_bus_for_each_resource(bus, r, i) {
+   struct resource avail;
+
if (!r)
continue;
 
@@ -147,10 +163,21 @@ pci_bus_alloc_resource(struct pci_bus *bus, struct 
resource *res,
!(res->flags & IORESOURCE_PREFETCH))
continue;
 
+   /*
+* don't allocate too high if the pref mem doesn't
+* support 64bit.
+*/
+   avail = *r;
+   if (!(res->flags & IORESOURCE_MEM_64)) {
+   pci_clip_resource(&avail, bus, &pci_mem_32);
+   if (!resource_size(&avail))
+   continue;
+   }
+
/* Ok, try it out.. */
ret = allocate_resource(r, res, size,
-   r->start ? : min,
-   max, align,
+   max(avail.start, r->start ? : min),
+   avail.end, align,
alignf, alignf_data);
if (ret == 0)
break;
diff --git a/include/linux/pci.h b/include/linux/pci.h
index da069fa..99e9040 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1485,10 +1485,6 @@ static inline struct pci_dev *pci_dev_get(struct pci_dev 
*dev)
 
 #include 
 
-#ifndef PCIBIOS_MAX_MEM_32
-#define PCIBIOS_MAX_MEM_32 (-1)
-#endif
-
 /* these helpers provide future and backwards compatibility
  * for accessing popular PCI BAR info */
 #define pci_resource_start(dev, bar)   ((dev)->resource[(bar)].start)
-- 
1.8.4

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

[PATCH v4 1/5] PCI: pcibus address to resource converting take bus instead of dev

[Yinghai Lu]

For allocating resource under bus path, we do not have dev to pass along,
and we only have bus to use instead.

-v2: drop pcibios_bus_addr_to_resource().
-v3: drop __* change requested by Bjorn.

Signed-off-by: Yinghai Lu 
Cc: linux-al...@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: sparcli...@vger.kernel.org
Cc: linux-pcm...@lists.infradead.org
Cc: linux-s...@vger.kernel.org
Cc: linux-fb...@vger.kernel.org
---
 arch/alpha/kernel/pci-sysfs.c   |  4 ++--
 arch/powerpc/kernel/pci-common.c|  4 ++--
 arch/powerpc/kernel/pci_of_scan.c   |  4 ++--
 arch/sparc/kernel/pci.c |  6 +++---
 drivers/pci/host-bridge.c   | 24 +++-
 drivers/pci/probe.c | 18 +-
 drivers/pci/quirks.c|  2 +-
 drivers/pci/rom.c   |  2 +-
 drivers/pci/setup-bus.c | 16 
 drivers/pci/setup-res.c |  2 +-
 drivers/pcmcia/i82092.c |  2 +-
 drivers/pcmcia/yenta_socket.c   |  6 +++---
 drivers/scsi/sym53c8xx_2/sym_glue.c |  5 +++--
 drivers/video/arkfb.c   |  2 +-
 drivers/video/s3fb.c|  2 +-
 drivers/video/vt8623fb.c|  2 +-
 include/linux/pci.h |  4 ++--
 17 files changed, 52 insertions(+), 53 deletions(-)

diff --git a/arch/alpha/kernel/pci-sysfs.c b/arch/alpha/kernel/pci-sysfs.c
index 2b183b0..99e8d47 100644
--- a/arch/alpha/kernel/pci-sysfs.c
+++ b/arch/alpha/kernel/pci-sysfs.c
@@ -83,7 +83,7 @@ static int pci_mmap_resource(struct kobject *kobj,
if (iomem_is_exclusive(res->start))
return -EINVAL;
 
-   pcibios_resource_to_bus(pdev, &bar, res);
+   pcibios_resource_to_bus(pdev->bus, &bar, res);
vma->vm_pgoff += bar.start >> (PAGE_SHIFT - (sparse ? 5 : 0));
mmap_type = res->flags & IORESOURCE_MEM ? pci_mmap_mem : pci_mmap_io;
 
@@ -139,7 +139,7 @@ static int sparse_mem_mmap_fits(struct pci_dev *pdev, int 
num)
long dense_offset;
unsigned long sparse_size;
 
-   pcibios_resource_to_bus(pdev, &bar, &pdev->resource[num]);
+   pcibios_resource_to_bus(pdev->bus, &bar, &pdev->resource[num]);
 
/* All core logic chips have 4G sparse address space, except
   CIA which has 16G (see xxx_SPARSE_MEM and xxx_DENSE_MEM
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index a1e3e40..d9476c1 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -835,7 +835,7 @@ static void pcibios_fixup_resources(struct pci_dev *dev)
 * at 0 as unset as well, except if PCI_PROBE_ONLY is also set
 * since in that case, we don't want to re-assign anything
 */
-   pcibios_resource_to_bus(dev, ®, res);
+   pcibios_resource_to_bus(dev->bus, ®, res);
if (pci_has_flag(PCI_REASSIGN_ALL_RSRC) ||
(reg.start == 0 && !pci_has_flag(PCI_PROBE_ONLY))) {
/* Only print message if not re-assigning */
@@ -886,7 +886,7 @@ static int pcibios_uninitialized_bridge_resource(struct 
pci_bus *bus,
 
/* Job is a bit different between memory and IO */
if (res->flags & IORESOURCE_MEM) {
-   pcibios_resource_to_bus(dev, ®ion, res);
+   pcibios_resource_to_bus(dev->bus, ®ion, res);
 
/* If the BAR is non-0 then it's probably been initialized */
if (region.start != 0)
diff --git a/arch/powerpc/kernel/pci_of_scan.c 
b/arch/powerpc/kernel/pci_of_scan.c
index ac0b034..83c26d8 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -111,7 +111,7 @@ static void of_pci_parse_addrs(struct device_node *node, 
struct pci_dev *dev)
res->name = pci_name(dev);
region.start = base;
region.end = base + size - 1;
-   pcibios_bus_to_resource(dev, res, ®ion);
+   pcibios_bus_to_resource(dev->bus, res, ®ion);
}
 }
 
@@ -280,7 +280,7 @@ void of_scan_pci_bridge(struct pci_dev *dev)
res->flags = flags;
region.start = of_read_number(&ranges[1], 2);
region.end = region.start + size - 1;
-   pcibios_bus_to_resource(dev, res, ®ion);
+   pcibios_bus_to_resource(dev->bus, res, ®ion);
}
sprintf(bus->name, "PCI Bus %04x:%02x", pci_domain_nr(bus),
bus->number);
diff --git a/arch/sparc/kernel/pci.c b/arch/sparc/kernel/pci.c
index cb02145..7de8d1f 100644
--- a/arch/sparc/kernel/pci.c
+++ b/arch/sparc/kernel/pci.c
@@ -392,7 +392,7 @@ static void apb_fake_ranges(struct pci_dev *dev,
res->flags = IORESOURCE_IO;
region.start = (first << 21);
region.end = (last << 21) + ((1 << 21) - 1);
-   pcibios_bus_to_resource(dev, res, ®ion);
+   pcibios_bus_to_resource(dev->bus, res, ®ion);
 
pci_read_config_byte(dev, APB_MEM_

[PATCH v4 3/5] PCI: Try to allocate mem64 above 4G at first

[Yinghai Lu]

On system with more pcie cards, we do not have enough range under 4G
to allocate those pci devices.

On 64bit system, we could try to allocate mem64 above 4G at first,
and fall back to below 4g if it can not find any above 4g.

x86 32bit without X86_PAE support will have bottom set to 0, because
resource_size_t is 32bit.
For 32bit kernel that resource_size_t is 64bit when pae is support.
we are safe because iomem_resource is limited to 32bit according to
x86_phys_bits.

-v2: update bottom assigning to make it clear for non-pae support machine.
-v3: Bjorn's change:
use MAX_RESOURCE instead of -1
use start/end instead of bottom/max
for all arch instead of just x86_64
-v4: updated after PCI_MAX_RESOURCE_32 change.
-v5: restore io handling to use PCI_MAX_RESOURCE_32 as limit.
-v6: checking pcibios_resource_to_bus return for every bus res, to decide it
if we need to try high at first.
 It supports all arches instead of just x86_64.
-v7: split 4G limit change out to another patch according to Bjorn.
 also use pci_clip_resource instead.

Signed-off-by: Yinghai Lu 
---
 drivers/pci/bus.c | 21 +++--
 1 file changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
index 3ad4fd9..45d8de5 100644
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -99,6 +99,8 @@ void pci_bus_remove_resources(struct pci_bus *bus)
 }
 
 static struct pci_bus_region pci_mem_32 = {0, 0x};
+static struct pci_bus_region pci_mem_64 = {(resource_size_t)(1ULL<<32),
+  (resource_size_t)(-1ULL)};
 
 static void pci_clip_resource(struct resource *res, struct pci_bus *bus,
  struct pci_bus_region *region)
@@ -149,6 +151,7 @@ pci_bus_alloc_resource(struct pci_bus *bus, struct resource 
*res,
 
pci_bus_for_each_resource(bus, r, i) {
struct resource avail;
+   int try_again = 0;
 
if (!r)
continue;
@@ -165,15 +168,23 @@ pci_bus_alloc_resource(struct pci_bus *bus, struct 
resource *res,
 
/*
 * don't allocate too high if the pref mem doesn't
-* support 64bit.
+* support 64bit, also if this is a 64-bit mem
+* resource, try above 4GB first
 */
avail = *r;
-   if (!(res->flags & IORESOURCE_MEM_64)) {
+   if (res->flags & IORESOURCE_MEM_64) {
+   pci_clip_resource(&avail, bus, &pci_mem_64);
+   if (!resource_size(&avail))
+   avail = *r;
+   else
+   try_again = 1;
+   } else {
pci_clip_resource(&avail, bus, &pci_mem_32);
if (!resource_size(&avail))
continue;
}
 
+again:
/* Ok, try it out.. */
ret = allocate_resource(r, res, size,
max(avail.start, r->start ? : min),
@@ -181,6 +192,12 @@ pci_bus_alloc_resource(struct pci_bus *bus, struct 
resource *res,
alignf, alignf_data);
if (ret == 0)
break;
+
+   if (try_again) {
+   avail = *r;
+   try_again = 0;
+   goto again;
+   }
}
return ret;
 }
-- 
1.8.4

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

[PATCH v4 4/5] PCI: Try best to allocate pref mmio 64bit above 4g

[Yinghai Lu]

When one of children resources does not support MEM_64, MEM_64 for
bridge get reset, so pull down whole pref resource on the bridge under 4G.

If the bridge support pref mem 64, will only allocate that with pref mem64 to
children that support it.
For children resources if they only support pref mem 32, will allocate them
from non pref mem instead.

If the bridge only support 32bit pref mmio, will still have all children pref
mmio under that.

-v2: Add release bridge res support with bridge mem res for pref_mem children 
res.
-v3: refresh and make it can be applied early before for_each_dev_res patchset.

Signed-off-by: Yinghai Lu 
Tested-by: Guo Chao 
---
 drivers/pci/setup-bus.c | 133 
 drivers/pci/setup-res.c |  14 -
 2 files changed, 101 insertions(+), 46 deletions(-)

diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 7933982..843764e 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -711,12 +711,11 @@ static void pci_bridge_check_ranges(struct pci_bus *bus)
bus resource of a given type. Note: we intentionally skip
the bus resources which have already been assigned (that is,
have non-NULL parent resource). */
-static struct resource *find_free_bus_resource(struct pci_bus *bus, unsigned 
long type)
+static struct resource *find_free_bus_resource(struct pci_bus *bus,
+unsigned long type_mask, unsigned long type)
 {
int i;
struct resource *r;
-   unsigned long type_mask = IORESOURCE_IO | IORESOURCE_MEM |
- IORESOURCE_PREFETCH;
 
pci_bus_for_each_resource(bus, r, i) {
if (r == &ioport_resource || r == &iomem_resource)
@@ -813,7 +812,8 @@ static void pbus_size_io(struct pci_bus *bus, 
resource_size_t min_size,
resource_size_t add_size, struct list_head *realloc_head)
 {
struct pci_dev *dev;
-   struct resource *b_res = find_free_bus_resource(bus, IORESOURCE_IO);
+   struct resource *b_res = find_free_bus_resource(bus, IORESOURCE_IO,
+   IORESOURCE_IO);
resource_size_t size = 0, size0 = 0, size1 = 0;
resource_size_t children_add_size = 0;
resource_size_t min_align, align;
@@ -913,15 +913,16 @@ static inline resource_size_t 
calculate_mem_align(resource_size_t *aligns,
  * guarantees that all child resources fit in this size.
  */
 static int pbus_size_mem(struct pci_bus *bus, unsigned long mask,
-unsigned long type, resource_size_t min_size,
-   resource_size_t add_size,
-   struct list_head *realloc_head)
+unsigned long type, unsigned long type2,
+resource_size_t min_size, resource_size_t add_size,
+struct list_head *realloc_head)
 {
struct pci_dev *dev;
resource_size_t min_align, align, size, size0, size1;
resource_size_t aligns[12]; /* Alignments from 1Mb to 2Gb */
int order, max_order;
-   struct resource *b_res = find_free_bus_resource(bus, type);
+   struct resource *b_res = find_free_bus_resource(bus,
+mask | IORESOURCE_PREFETCH, type);
unsigned int mem64_mask = 0;
resource_size_t children_add_size = 0;
 
@@ -942,7 +943,8 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned long 
mask,
struct resource *r = &dev->resource[i];
resource_size_t r_size;
 
-   if (r->parent || (r->flags & mask) != type)
+   if (r->parent || ((r->flags & mask) != type &&
+ (r->flags & mask) != type2))
continue;
r_size = resource_size(r);
 #ifdef CONFIG_PCI_IOV
@@ -1115,8 +1117,9 @@ void __ref __pci_bus_size_bridges(struct pci_bus *bus,
struct list_head *realloc_head)
 {
struct pci_dev *dev;
-   unsigned long mask, prefmask;
+   unsigned long mask, prefmask, type2 = 0;
resource_size_t additional_mem_size = 0, additional_io_size = 0;
+   struct resource *b_res;
 
list_for_each_entry(dev, &bus->devices, bus_list) {
struct pci_bus *b = dev->subordinate;
@@ -1161,15 +1164,31 @@ void __ref __pci_bus_size_bridges(struct pci_bus *bus,
   has already been allocated by arch code, try
   non-prefetchable range for both types of PCI memory
   resources. */
+   b_res = &bus->self->resource[PCI_BRIDGE_RESOURCES];
mask = IORESOURCE_MEM;
prefmask = IORESOURCE_MEM | IORESOURCE_PREFETCH;
-   if (pbus_size_mem(bus, prefmask, prefmask,
+   if (b_res[2].flags & IORESOURCE_MEM_64) {
+   prefmask |= IORESOURCE_MEM_64;

[PATCH v4 5/5] PCI: Sort pci root bus resources list

[Yinghai Lu]

Some x86 systems expose above 4G 64bit mmio in _CRS as non-pref mmio range.
[   49.415281] PCI host bridge to bus :00
[   49.419921] pci_bus :00: root bus resource [bus 00-1e]
[   49.426107] pci_bus :00: root bus resource [io  0x-0x0cf7]
[   49.433041] pci_bus :00: root bus resource [io  0x1000-0x5fff]
[   49.440010] pci_bus :00: root bus resource [mem 0x000a-0x000b]
[   49.447768] pci_bus :00: root bus resource [mem 0xfed8c000-0xfedf]
[   49.455532] pci_bus :00: root bus resource [mem 0x9000-0x9fffbfff]
[   49.463259] pci_bus :00: root bus resource [mem 
0x3800-0x381f]

During assign unassigned 64bit mmio resource, it will go through
every non-pref mmio for root bus in pci_bus_alloc_resource().
As the loop is with pci_bus_for_each_resource(), and could have chance
to use under 4G mmio range instead of above 4G mmio range if the requested
range is not big enough, even it could handle above 4G 64bit pref mmio.

For root bus, we can order list from high to low in pci_add_resource_offset(),
during creating root bus, it will still keep the same order in final bus
resource list.
pci_acpi_scan_root
==> add_resources
==> pci_add_resource_offset: # Add to temp resources
==> pci_create_root_bus
==> pci_bus_add_resource # add to final bus resources.

After that, we can make sure 64bit pref mmio for pci bridges will be allocated
higest of mmio non-pref, and in this case it is above 4G instead of under 4G.

Signed-off-by: Yinghai Lu 
---
 drivers/pci/bus.c | 15 +--
 1 file changed, 13 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
index 45d8de5..7798cd3 100644
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -21,7 +21,8 @@
 void pci_add_resource_offset(struct list_head *resources, struct resource *res,
 resource_size_t offset)
 {
-   struct pci_host_bridge_window *window;
+   struct pci_host_bridge_window *window, *tmp;
+   struct list_head *n;
 
window = kzalloc(sizeof(struct pci_host_bridge_window), GFP_KERNEL);
if (!window) {
@@ -31,7 +32,17 @@ void pci_add_resource_offset(struct list_head *resources, 
struct resource *res,
 
window->res = res;
window->offset = offset;
-   list_add_tail(&window->list, resources);
+
+   /* Keep list sorted according to res end */
+   n = resources;
+   list_for_each_entry(tmp, resources, list)
+   if (window->res->end > tmp->res->end) {
+   n = &tmp->list;
+   break;
+   }
+
+   /* Insert it just before n */
+   list_add_tail(&window->list, n);
 }
 EXPORT_SYMBOL(pci_add_resource_offset);
 
-- 
1.8.4

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

[PATCH v4 0/5] PCI: allocate 64bit mmio pref

[Yinghai Lu]

mmio 64 allocation that could help Guo Chao  on 
powerpc mmio allocation.
It will try to assign 64 bit resource above 4g at first.

And it is based on current pci/for-linus.

-v2: update after patch that move device_del down to pci_destroy_dev.
 add "Try best to allocate pref mmio 64bit above 4G"

-v3: refresh and send out after pci_clip_resource() changes,
 as Bjorn is not happy with attachments.

-v4: make pcibios_resource_to_bus take bus directly.

Yinghai Lu (5):
  PCI: pcibus address to resource converting take bus instead of dev
  PCI: Don't use 4G bus address directly in resource allocation
  PCI: Try to allocate mem64 above 4G at first
  PCI: Try best to allocate pref mmio 64bit above 4g
  PCI: Sort pci root bus resources list

 arch/alpha/kernel/pci-sysfs.c   |   4 +-
 arch/powerpc/kernel/pci-common.c|   4 +-
 arch/powerpc/kernel/pci_of_scan.c   |   4 +-
 arch/sparc/kernel/pci.c |   6 +-
 arch/x86/include/asm/pci.h  |   1 -
 drivers/pci/bus.c   |  73 +++---
 drivers/pci/host-bridge.c   |  24 +++---
 drivers/pci/probe.c |  18 ++---
 drivers/pci/quirks.c|   2 +-
 drivers/pci/rom.c   |   2 +-
 drivers/pci/setup-bus.c | 149 +++-
 drivers/pci/setup-res.c |  16 +++-
 drivers/pcmcia/i82092.c |   2 +-
 drivers/pcmcia/yenta_socket.c   |   6 +-
 drivers/scsi/sym53c8xx_2/sym_glue.c |   5 +-
 drivers/video/arkfb.c   |   2 +-
 drivers/video/s3fb.c|   2 +-
 drivers/video/vt8623fb.c|   2 +-
 include/linux/pci.h |   8 +-
 19 files changed, 217 insertions(+), 113 deletions(-)

-- 
1.8.4

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

Re: [PATCH] gadget: make USB_CONFIGFS_MASS_STORAGE depend on BLOCK

[Andrzej Pietrasiewicz]

W dniu 09.12.2013 20:18, Randy Dunlap pisze:

From: Randy Dunlap 

Make USB_CONFIGFS_MASS_STORAGE depend on BLOCK just like the other
gadget MASS_STORAGE options do.  This fixes the following build errors
that occur when BLOCK is not enabled:


Already submitted

http://www.spinics.net/lists/linux-usb/msg96739.html

AP




drivers/usb/gadget/storage_common.c: In function 'fsg_lun_open':
drivers/usb/gadget/storage_common.c:241:3: error: implicit declaration of 
function 'bdev_logical_block_size' [-Werror=implicit-function-declaration]
drivers/usb/gadget/storage_common.c:242:3: error: implicit declaration of 
function 'blksize_bits' [-Werror=implicit-function-declaration]

Signed-off-by: Randy Dunlap 
Cc: Andrzej Pietrasiewicz 
Cc: Felipe Balbi 
---
  drivers/usb/gadget/Kconfig |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

--- lnx-313-rc3.orig/drivers/usb/gadget/Kconfig
+++ lnx-313-rc3/drivers/usb/gadget/Kconfig
@@ -681,7 +681,7 @@ config USB_CONFIGFS_PHONET

  config USB_CONFIGFS_MASS_STORAGE
boolean "Mass storage"
-   depends on USB_CONFIGFS
+   depends on USB_CONFIGFS && BLOCK
select USB_F_MASS_STORAGE
help
  The Mass Storage Gadget acts as a USB Mass Storage disk drive.
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



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

RE: [PATCH] Documentation: move intel_txt.txt to Documentation/x86

[Wei, Gang]

Ren, Qiaowei wrote on 2013-12-10:
> Documentation/x86 is a more fitting place for intel_txt.txt.
> 
> Signed-off-by: Qiaowei Ren 
> ---
>  Documentation/intel_txt.txt |  210
>  --- Documentation/x86/intel_txt.txt
>  |  210 +++ 2 files changed, 210
>  insertions(+), 210 deletions(-) delete mode 100644
>  Documentation/intel_txt.txt create mode 100644
>  Documentation/x86/intel_txt.txt

Ack.

Jimmy


smime.p7s
Description: S/MIME cryptographic signature

Re: [PATCH v3 09/12] sched/numa: fix task scan rate adjustment

[Naoya Horiguchi]

Hi Wanpeng,

On Sun, Dec 08, 2013 at 02:14:50PM +0800, Wanpeng Li wrote:
> commit 04bb2f947 (sched/numa: Adjust scan rate in task_numa_placement) 
> calculate
> period_slot which should be used as base value of scan rate increase if remote
> access dominate. However, current codes forget to use it, this patch fix it.
> 
> Signed-off-by: Wanpeng Li 
> ---
>  kernel/sched/fair.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 7073c76..b077f1b3 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -1358,7 +1358,7 @@ static void update_task_scan_period(struct task_struct 
> *p,
>*/
>   period_slot = DIV_ROUND_UP(diff, NUMA_PERIOD_SLOTS);
>   ratio = DIV_ROUND_UP(private * NUMA_PERIOD_SLOTS, (private + 
> shared));
> - diff = (diff * ratio) / NUMA_PERIOD_SLOTS;
> + diff = (period_slot * ratio) / NUMA_PERIOD_SLOTS;
>   }
>  
>   p->numa_scan_period = clamp(p->numa_scan_period + diff,

It seems to me that the original code is correct, because the mathematical
meaning of this hunk is clear:

  diff = (diff calculated by local-remote ratio) * (private-shared ratio)

If you use period_slot here, diff always becomes less then 1/10 finally by
the second ratio multiplication (because we divide by NUMA_PERIOD_SLOTS twice),
and I don't see the justification.

And if my idea is correct, we don't have to recalculate period_slot when
we multiply private-shared ratio. So we can remove that line.

Thanks,
Naoya Horiguchi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 v11 4/4] ARM: dts: Exynos5420: Add device nodes for TMU blocks

[Naveen Krishna Chatradhi]

Exynos5420 SoC has per core thermal management unit.
5 TMU channels 4 for CPUs and 5th for GPU.

This patch adds the device tree nodes to the DT device list.

Nodes carry the misplaced second base address and the second
clock to access the misplaced base address.

Signed-off-by: Leela Krishna Amudala 
Signed-off-by: Naveen Krishna Chatradhi 
Signed-off-by: Andrew Bresticker 
---
Changes since previous version:
1. used lables instead of comment lines
2. pass the same clock as trimfo_apbif clock for TMU channel 2

 arch/arm/boot/dts/exynos5420.dtsi |   40 +
 1 file changed, 40 insertions(+)

diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index b1fa334..c62cde6 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -402,4 +402,44 @@
clock-names = "gscl";
samsung,power-domain = <&gsc_pd>;
};
+
+   tmu_cpu0:tmu@1006 {
+   compatible = "samsung,exynos5420-tmu";
+   reg = <0x1006 0x100>;
+   interrupts = <0 65 0>;
+   clocks = <&clock 318>;
+   clock-names = "tmu_apbif";
+   };
+
+   tmu_cpu1:tmu@10064000 {
+   compatible = "samsung,exynos5420-tmu";
+   reg = <0x10064000 0x100>;
+   interrupts = <0 183 0>;
+   clocks = <&clock 318>;
+   clock-names = "tmu_apbif";
+   };
+
+   tmu_cpu2:tmu@10068000 {
+   compatible = "samsung,exynos5420-tmu-ext-triminfo";
+   reg = <0x10068000 0x100>, <0x1006c000 0x4>;
+   interrupts = <0 184 0>;
+   clocks = <&clock 318>, <&clock 318>;
+   clock-names = "tmu_apbif", "tmu_apbif_triminfo";
+   };
+
+   tmu_cpu3:tmu@1006c000 {
+   compatible = "samsung,exynos5420-tmu-ext-triminfo";
+   reg = <0x1006c000 0x100>, <0x100a 0x4>;
+   interrupts = <0 185 0>;
+   clocks = <&clock 318>, <&clock 319>;
+   clock-names = "tmu_apbif", "tmu_apbif_triminfo";
+   };
+
+   tmu_gpu:tmu@100a {
+   compatible = "samsung,exynos5420-tmu-ext-triminfo";
+   reg = <0x100a 0x100>, <0x10068000 0x4>;
+   interrupts = <0 215 0>;
+   clocks = <&clock 319>, <&clock 318>;
+   clock-names = "tmu_apbif", "tmu_apbif_triminfo";
+   };
 };
-- 
1.7.10.4

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

[PATCH v11 3/4] thermal: samsung: Add TMU support for Exynos5420 SoCs

[Naveen Krishna Chatradhi]

Exynos5420 has 5 TMU channels, the TRIMINFO register is
misplaced for TMU channels 2, 3 and 4
TRIMINFO at 0x1006c000 contains data for TMU channel 3
TRIMINFO at 0x100a contains data for TMU channel 4
TRIMINFO at 0x10068000 contains data for TMU channel 2

This patch
1 Adds the neccessary register changes and arch information
   to support Exynos5420 SoCs.
2. Handles the gate clock for misplaced TRIMINFO register
3. Updates the Documentation at
   Documentation/devicetree/bindings/thermal/exynos-thermal.txt

Signed-off-by: Naveen Krishna Chatradhi 
Signed-off-by: Andrew Bresticker 
Acked-by: Amit Daniel Kachhap 
Reviewed-by: Bartlomiej Zolnierkiewicz 
---
Changes since v10:
1. using renamed compatible "samsung,exynos5420-tmu-ext-triminfo"
   and passing same clock as triminfo_apbif clock for channel 2
2. removed the "exynos5420-tmu-triminfo-clk" compatible

 .../devicetree/bindings/thermal/exynos-thermal.txt |   38 
 drivers/thermal/samsung/exynos_tmu.c   |   52 +-
 drivers/thermal/samsung/exynos_tmu.h   |1 +
 drivers/thermal/samsung/exynos_tmu_data.c  |   99 
 drivers/thermal/samsung/exynos_tmu_data.h  |8 ++
 5 files changed, 194 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index a1aa602..a3e78c0 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -6,6 +6,9 @@
   "samsung,exynos4412-tmu"
   "samsung,exynos4210-tmu"
   "samsung,exynos5250-tmu"
+  "samsung,exynos5420-tmu" for TMU channel 0, 1 on Exynos5420
+  "samsung,exynos5420-tmu-ext-triminfo" for TMU channels 2, 3 and 4
+   Exynos5420 (Must pass triminfo base and triminfo clock)
   "samsung,exynos5440-tmu"
 - interrupt-parent : The phandle for the interrupt controller
 - reg : Address range of the thermal registers. For soc's which has multiple
@@ -13,6 +16,16 @@
interrupt related then 2 set of register has to supplied. First set
belongs to register set of TMU instance and second set belongs to
registers shared with the TMU instance.
+
+  NOTE: On Exynos5420, the TRIMINFO register is misplaced for TMU
+   channels 2, 3 and 4
+   Use "samsung,exynos5420-tmu-ext-triminfo" in cases, there is a misplaced
+   register, also provide clock to access that base.
+
+   TRIMINFO at 0x1006c000 contains data for TMU channel 3
+   TRIMINFO at 0x100a contains data for TMU channel 4
+   TRIMINFO at 0x10068000 contains data for TMU channel 2
+
 - interrupts : Should contain interrupt for thermal system
 - clocks : The main clock for TMU device
 - clock-names : Thermal system clock name
@@ -43,6 +56,31 @@ Example 2):
clock-names = "tmu_apbif";
};
 
+Example 3): (In case of Exynos5420 "with misplaced TRIMINFO register")
+   tmu_cpu2: tmu@10068000 {
+   compatible = "samsung,exynos5420-tmu-ext-triminfo";
+   reg = <0x10068000 0x100>, <0x1006c000 0x4>;
+   interrupts = <0 184 0>;
+   clocks = <&clock 318>, <&clock 318>;
+   clock-names = "tmu_apbif", "tmu_triminfo_apbif";
+   };
+
+   tmu_cpu3: tmu@1006c000 {
+   compatible = "samsung,exynos5420-tmu-ext-triminfo";
+   reg = <0x1006c000 0x100>, <0x100a 0x4>;
+   interrupts = <0 185 0>;
+   clocks = <&clock 318>, <&clock 319>;
+   clock-names = "tmu_apbif", "tmu_triminfo_apbif";
+   };
+
+   tmu_gpu: tmu@100a {
+   compatible = "samsung,exynos5420-tmu-ext-triminfo";
+   reg = <0x100a 0x100>, <0x10068000 0x4>;
+   interrupts = <0 215 0>;
+   clocks = <&clock 319>, <&clock 318>;
+   clock-names = "tmu_apbif", "tmu_triminfo_apbif";
+   };
+
 Note: For multi-instance tmu each instance should have an alias correctly
 numbered in "aliases" node.
 
diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index bbd0fc3..6f40c91 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -47,6 +47,7 @@
  * @irq_work: pointer to the irq work structure.
  * @lock: lock to implement synchronization.
  * @clk: pointer to the clock structure.
+ * @clk_sec: pointer to the clock structure for accessing the base_second.
  * @temp_error1: fused value of the first point trim.
  * @temp_error2: fused value of the second point trim.
  * @regulator: pointer to the TMU regulator structure.
@@ -61,7 +62,7 @@ struct exynos_tmu_data {
enum soc_type soc;
struct work_struct irq_work;
struct mutex lock;
-   struct clk *clk;
+   struct clk *clk, *clk_sec;
u8 temp_error1, tem

[PATCH v11 2/4] thermal: samsung: change base_common to more meaningful base_second

[Naveen Krishna Chatradhi]

On Exynos5440 and Exynos5420 there are registers common
across the TMU channels.

To support that, we introduced a ADDRESS_MULTIPLE flag in the
driver and the 2nd set of register base and size are provided
in the "reg" property of the node.

As per Amit's suggestion, this patch changes the base_common
to base_second and SHARED_MEMORY to ADDRESS_MULTIPLE.

Signed-off-by: Naveen Krishna Chatradhi 
Acked-by: Amit Daniel Kachhap 
Reviewed-by: Bartlomiej Zolnierkiewicz 
---
Changes since v10:
Documentation rephrased as per comments from Tomasz Figa

 .../devicetree/bindings/thermal/exynos-thermal.txt   |4 ++--
 drivers/thermal/samsung/exynos_tmu.c |   14 +++---
 drivers/thermal/samsung/exynos_tmu.h |4 ++--
 drivers/thermal/samsung/exynos_tmu_data.c|2 +-
 4 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt 
b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
index 284f530..a1aa602 100644
--- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
+++ b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt
@@ -11,8 +11,8 @@
 - reg : Address range of the thermal registers. For soc's which has multiple
instances of TMU and some registers are shared across all TMU's like
interrupt related then 2 set of register has to supplied. First set
-   belongs to each instance of TMU and second set belongs to common TMU
-   registers.
+   belongs to register set of TMU instance and second set belongs to
+   registers shared with the TMU instance.
 - interrupts : Should contain interrupt for thermal system
 - clocks : The main clock for TMU device
 - clock-names : Thermal system clock name
diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index c493245..bbd0fc3 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -41,7 +41,7 @@
  * @id: identifier of the one instance of the TMU controller.
  * @pdata: pointer to the tmu platform/configuration data
  * @base: base address of the single instance of the TMU controller.
- * @base_common: base address of the common registers of the TMU controller.
+ * @base_second: base address of the common registers of the TMU controller.
  * @irq: irq number of the TMU controller.
  * @soc: id of the SOC type.
  * @irq_work: pointer to the irq work structure.
@@ -56,7 +56,7 @@ struct exynos_tmu_data {
int id;
struct exynos_tmu_platform_data *pdata;
void __iomem *base;
-   void __iomem *base_common;
+   void __iomem *base_second;
int irq;
enum soc_type soc;
struct work_struct irq_work;
@@ -297,7 +297,7 @@ skip_calib_data:
}
/*Clear the PMIN in the common TMU register*/
if (reg->tmu_pmin && !data->id)
-   writel(0, data->base_common + reg->tmu_pmin);
+   writel(0, data->base_second + reg->tmu_pmin);
 out:
clk_disable(data->clk);
mutex_unlock(&data->lock);
@@ -454,7 +454,7 @@ static void exynos_tmu_work(struct work_struct *work)
 
/* Find which sensor generated this interrupt */
if (reg->tmu_irqstatus) {
-   val_type = readl(data->base_common + reg->tmu_irqstatus);
+   val_type = readl(data->base_second + reg->tmu_irqstatus);
if (!((val_type >> data->id) & 0x1))
goto out;
}
@@ -579,7 +579,7 @@ static int exynos_map_dt_data(struct platform_device *pdev)
 * Check if the TMU shares some registers and then try to map the
 * memory of common registers.
 */
-   if (!TMU_SUPPORTS(pdata, SHARED_MEMORY))
+   if (!TMU_SUPPORTS(pdata, ADDRESS_MULTIPLE))
return 0;
 
if (of_address_to_resource(pdev->dev.of_node, 1, &res)) {
@@ -587,9 +587,9 @@ static int exynos_map_dt_data(struct platform_device *pdev)
return -ENODEV;
}
 
-   data->base_common = devm_ioremap(&pdev->dev, res.start,
+   data->base_second = devm_ioremap(&pdev->dev, res.start,
resource_size(&res));
-   if (!data->base_common) {
+   if (!data->base_second) {
dev_err(&pdev->dev, "Failed to ioremap memory\n");
return -ENOMEM;
}
diff --git a/drivers/thermal/samsung/exynos_tmu.h 
b/drivers/thermal/samsung/exynos_tmu.h
index 980859a..0d6b32f 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -60,7 +60,7 @@ enum soc_type {
  * state(active/idle) can be checked.
  * TMU_SUPPORT_EMUL_TIME - This features allows to set next temp emulation
  * sample time.
- * TMU_SUPPORT_SHARED_MEMORY - This feature tells that the different TMU
+ * TMU_SUPPORT_ADDRESS_MULTIPLE - This feature tells that the different TMU
  *

[PATCH v11 1/4] thermal: samsung: replace inten_ bit fields with intclr_

[Naveen Krishna Chatradhi]

This patch replaces the inten_rise_shift/mask and inten_fall_shift/mask
with intclr_rise_shift/mask and intclr_fall_shift/mask respectively.
Currently, inten_rise_shift/mask and inten_fall_shift/mask bits are only used
to configure intclr related registers.

Description of H/W:
The offset for the bits in the CLEAR register are not consistent across TMU
modules in Exynso5250, 5420 and 5440.

On Exynos5250, the FALL interrupt related en, status and clear bits are
available at an offset of
16 in INTEN, INTSTAT registers and at an offset of
12 in INTCLEAR register.

On Exynos5420, the FALL interrupt related en, status and clear bits are
available at an offset of
16 in INTEN, INTSTAT and INTCLEAR registers.

On Exynos5440,
the FALL_IRQEN bits are at an offset of 4
and the RISE_IRQEN bits are at an offset of 0

Signed-off-by: Naveen Krishna Chatradhi 
Acked-by: Amit Daniel Kachhap 
Reviewed-by: Bartlomiej Zolnierkiewicz 
---
Changes since v10:
None

 drivers/thermal/samsung/exynos_tmu.c  |6 +++---
 drivers/thermal/samsung/exynos_tmu.h  |   16 
 drivers/thermal/samsung/exynos_tmu_data.c |   18 +-
 drivers/thermal/samsung/exynos_tmu_data.h |4 ++--
 4 files changed, 22 insertions(+), 22 deletions(-)

diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index 32f38b9..c493245 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -237,7 +237,7 @@ skip_calib_data:
writeb(pdata->trigger_levels[i], data->base +
reg->threshold_th0 + i * sizeof(reg->threshold_th0));
 
-   writel(reg->inten_rise_mask, data->base + reg->tmu_intclear);
+   writel(reg->intclr_rise_mask, data->base + reg->tmu_intclear);
} else {
/* Write temperature code for rising and falling threshold */
for (i = 0;
@@ -264,8 +264,8 @@ skip_calib_data:
writel(falling_threshold,
data->base + reg->threshold_th1);
 
-   writel((reg->inten_rise_mask << reg->inten_rise_shift) |
-   (reg->inten_fall_mask << reg->inten_fall_shift),
+   writel((reg->intclr_rise_mask << reg->intclr_rise_shift) |
+   (reg->intclr_fall_mask << reg->intclr_fall_shift),
data->base + reg->tmu_intclear);
 
/* if last threshold limit is also present */
diff --git a/drivers/thermal/samsung/exynos_tmu.h 
b/drivers/thermal/samsung/exynos_tmu.h
index 3fb6554..980859a 100644
--- a/drivers/thermal/samsung/exynos_tmu.h
+++ b/drivers/thermal/samsung/exynos_tmu.h
@@ -122,10 +122,6 @@ enum soc_type {
  * @threshold_th3_l0_shift: shift bits of level0 threshold temperature.
  * @tmu_inten: register containing the different threshold interrupt
enable bits.
- * @inten_rise_shift: shift bits of all rising interrupt bits.
- * @inten_rise_mask: mask bits of all rising interrupt bits.
- * @inten_fall_shift: shift bits of all rising interrupt bits.
- * @inten_fall_mask: mask bits of all rising interrupt bits.
  * @inten_rise0_shift: shift bits of rising 0 interrupt bits.
  * @inten_rise1_shift: shift bits of rising 1 interrupt bits.
  * @inten_rise2_shift: shift bits of rising 2 interrupt bits.
@@ -136,6 +132,10 @@ enum soc_type {
  * @inten_fall3_shift: shift bits of falling 3 interrupt bits.
  * @tmu_intstat: Register containing the interrupt status values.
  * @tmu_intclear: Register for clearing the raised interrupt status.
+ * @intclr_fall_shift: shift bits for interrupt clear fall 0
+ * @intclr_rise_shift: shift bits of all rising interrupt bits.
+ * @intclr_rise_mask: mask bits of all rising interrupt bits.
+ * @intclr_fall_mask: mask bits of all rising interrupt bits.
  * @emul_con: TMU emulation controller register.
  * @emul_temp_shift: shift bits of emulation temperature.
  * @emul_time_shift: shift bits of emulation time.
@@ -191,10 +191,6 @@ struct exynos_tmu_registers {
u32 threshold_th3_l0_shift;
 
u32 tmu_inten;
-   u32 inten_rise_shift;
-   u32 inten_rise_mask;
-   u32 inten_fall_shift;
-   u32 inten_fall_mask;
u32 inten_rise0_shift;
u32 inten_rise1_shift;
u32 inten_rise2_shift;
@@ -207,6 +203,10 @@ struct exynos_tmu_registers {
u32 tmu_intstat;
 
u32 tmu_intclear;
+   u32 intclr_fall_shift;
+   u32 intclr_rise_shift;
+   u32 intclr_fall_mask;
+   u32 intclr_rise_mask;
 
u32 emul_con;
u32 emul_temp_shift;
diff --git a/drivers/thermal/samsung/exynos_tmu_data.c 
b/drivers/thermal/samsung/exynos_tmu_data.c
index 073c292..7cdb04e 100644
--- a/drivers/thermal/samsung/exynos_tmu_data.c
+++ b/drivers/thermal/samsung/exynos_tmu_data.c
@@ -40,13 +40,13 @@ static const struct exynos_tmu_registers 
exynos4210_tmu_registers = {

[PATCH v11 0/4] thermal: samsung: Clean up and add support for Exynos5420

[Naveen Krishna Chatradhi]

This patchset does a little clean up of the existing code (linux-soc-thermal)
1.  [v11] thermal: samsung: replace inten_ bit fields with intclr_
2.  [v11] thermal: samsung: change base_common to more meaningful base_second

adds support for Exynos5420 in the driver and (linux-soc-thermal)
3.  [v11] thermal: samsung: Add TMU support for Exynos5420 SoCs
also adds the device tree nodes for the same to exynos5420.dtsi 
(linux-samsung.git)
4.  [v11] ARM: dts: Exynos5420: Add device nodes for TMU blocks

(linux-soc-thermal)
Naveen Krishna Chatradhi (3):
  thermal: samsung: replace inten_ bit fields with intclr_
  thermal: samsung: change base_common to more meaningful base_second
  thermal: samsung: Add TMU support for Exynos5420 SoCs

 .../devicetree/bindings/thermal/exynos-thermal.txt |   42 ++-
 drivers/thermal/samsung/exynos_tmu.c   |   72 +---
 drivers/thermal/samsung/exynos_tmu.h   |   21 ++--
 drivers/thermal/samsung/exynos_tmu_data.c  |  119 ++--
 drivers/thermal/samsung/exynos_tmu_data.h  |   12 +-
 5 files changed, 228 insertions(+), 38 deletions(-)

(linux-samsung.git)
Naveen Krishna Chatradhi (1):
  ARM: dts: Exynos5420: Add device nodes for TMU blocks

 arch/arm/boot/dts/exynos5420.dtsi |   40 +
 1 file changed, 40 insertions(+)
-- 
1.7.10.4

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

Re: questions of cpuidle

[Alex Shi]

On 12/09/2013 10:17 PM, Daniel Lezcano wrote:
> 
> Concerning the wake up of the cpu: the cpu disabled the irq and goes to
> sleep, it is up to the firmware to wake up the cpu when an interrupt
> occurs. It will exits its sleep state, call clock_events_notify(EXIT),
> by this way re-switching to the local timer, and then re-enabling the
> local interrupt which leads to the interrupt handler.

Thanks a lots for excellent article and detailed explains!

So, if the firmware is in response to wake up cpu. that means there is a
unit which control the firmware and it can not be power down. Do you
know which unit running the firmware to wake up deep idle CPU.
And does the wake up pass via GIC to CPU? If so, does the GIC need keep
awake when all cpu idle? If not, how the firmware give the interrupt to
CPU? And I am wondering if the deep idle cpu voltage get to near 0.
How the cpu get the interrupt signal?

> 
> There are some more informations in the wiki page [1].
> 
>   -- Daniel
> 
> [1] https://wiki.linaro.org/WorkingGroups/PowerManagement/Doc/WakeUpSources


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

ATTENTION:

[Membership Authentification Form]

ATTENTION:

Monday 9th of  December 2013 08:16:22 MYT from 41.206.151.183, your account
was recently accessed with this details, please if you recognize this
details,ignore this message, or use this web link to reconfirm your
account details to prevent spammers and unauthorized users to gain access
to your account;

http://www.emailmeform.com/builder/form/z7KbBhGaf0YV9X4

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

Re: ARM: nommu: DEBUG_LOCKS_WARN_ON(!depth)

[Axel Lin]

2013/11/25 Axel Lin :
> I'm testing on a nommu platform (arm7tdmi SoC).
> Using current Linus' tree + out-of-tree patches for this SoC.
> I got below hang while executing ls (busybox) after boot.
>
> / # ls
> [   51.036191] [ cut here ]
> [   51.042242] WARNING: CPU: 0 PID: 1 at kernel/locking/lockdep.c:3312 
> lock_set_class+0x5c8/0x660()
> [   51.051426] DEBUG_LOCKS_WARN_ON(!depth)
> [   51.055842] CPU: 0 PID: 1 Comm:  Not tainted 
> 3.13.0-rc1-00100-g4b061f7-dirty #1917
> [   51.065415] [] (unwind_backtrace+0x0/0xe0) from [] 
> (show_stack+0x10/0x14)
> [   51.075781] [] (show_stack+0x10/0x14) from [] 
> (warn_slowpath_common+0x58/0x78)
> [   51.086549] [] (warn_slowpath_common+0x58/0x78) from 
> [] (warn_slowpath_fmt+0x2c/0x3c)
> [   51.098162] [] (warn_slowpath_fmt+0x2c/0x3c) from [<00036d9c>] 
> (lock_set_class+0x5c8/0x660)
> [   50.934805] [<00036d9c>] (lock_set_class+0x5c8/0x660) from [<000367d4>] 
> (lock_set_class+0x0/0x660)
> [   50.945255] [<000367d4>] (lock_set_class+0x0/0x660) from [<>] (  
> (null))
> [   50.953242] ---[ end trace 7d1e4eb80001 ]---
>

Now test on top of linux-3.13-rc3.
I found I can hit this lockdep warning only when CONFIG_PREEMPT_NONE=y

1) With CONFIG_PREEMPT_NONE=y
executing ls (busybox) hang with above lockdep warning.
2) With CONFIG_PREEMPT_VOLUNTARY=y:
have "[sched_delayed] sched: RT throttling activated" in boot message.
executing ls (busybox) hang silently.
3) With CONFIG_PREEMPT=y:
executing ls (busybox) successfully and it's ok to execute other binary.

all the test with below configs:
CONFIG_PREEMPT_COUNT=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCKDEP=y
CONFIG_DEBUG_ATOMIC_SLEEP=y
CONFIG_TRACE_IRQFLAGS=y
CONFIG_STACKTRACE=y
CONFIG_DEBUG_BUGVERBOSE=y
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Documentation: move intel_txt.txt to Documentation/x86

[Qiaowei Ren]

Documentation/x86 is a more fitting place for intel_txt.txt.

Signed-off-by: Qiaowei Ren 
---
 Documentation/intel_txt.txt |  210 ---
 Documentation/x86/intel_txt.txt |  210 +++
 2 files changed, 210 insertions(+), 210 deletions(-)
 delete mode 100644 Documentation/intel_txt.txt
 create mode 100644 Documentation/x86/intel_txt.txt

diff --git a/Documentation/intel_txt.txt b/Documentation/intel_txt.txt
deleted file mode 100644
index 91d89c5..000
--- a/Documentation/intel_txt.txt
+++ /dev/null
@@ -1,210 +0,0 @@
-Intel(R) TXT Overview:
-=
-
-Intel's technology for safer computing, Intel(R) Trusted Execution
-Technology (Intel(R) TXT), defines platform-level enhancements that
-provide the building blocks for creating trusted platforms.
-
-Intel TXT was formerly known by the code name LaGrande Technology (LT).
-
-Intel TXT in Brief:
-o  Provides dynamic root of trust for measurement (DRTM)
-o  Data protection in case of improper shutdown
-o  Measurement and verification of launched environment
-
-Intel TXT is part of the vPro(TM) brand and is also available some
-non-vPro systems.  It is currently available on desktop systems
-based on the Q35, X38, Q45, and Q43 Express chipsets (e.g. Dell
-Optiplex 755, HP dc7800, etc.) and mobile systems based on the GM45,
-PM45, and GS45 Express chipsets.
-
-For more information, see http://www.intel.com/technology/security/.
-This site also has a link to the Intel TXT MLE Developers Manual,
-which has been updated for the new released platforms.
-
-Intel TXT has been presented at various events over the past few
-years, some of which are:
-  LinuxTAG 2008:
-  http://www.linuxtag.org/2008/en/conf/events/vp-donnerstag.html
-  TRUST2008:
-  http://www.trust-conference.eu/downloads/Keynote-Speakers/
-  3_David-Grawrock_The-Front-Door-of-Trusted-Computing.pdf
-  IDF, Shanghai:
-  http://www.prcidf.com.cn/index_en.html
-  IDFs 2006, 2007 (I'm not sure if/where they are online)
-
-Trusted Boot Project Overview:
-=
-
-Trusted Boot (tboot) is an open source, pre-kernel/VMM module that
-uses Intel TXT to perform a measured and verified launch of an OS
-kernel/VMM.
-
-It is hosted on SourceForge at http://sourceforge.net/projects/tboot.
-The mercurial source repo is available at http://www.bughost.org/
-repos.hg/tboot.hg.
-
-Tboot currently supports launching Xen (open source VMM/hypervisor
-w/ TXT support since v3.2), and now Linux kernels.
-
-
-Value Proposition for Linux or "Why should you care?"
-=
-
-While there are many products and technologies that attempt to
-measure or protect the integrity of a running kernel, they all
-assume the kernel is "good" to begin with.  The Integrity
-Measurement Architecture (IMA) and Linux Integrity Module interface
-are examples of such solutions.
-
-To get trust in the initial kernel without using Intel TXT, a
-static root of trust must be used.  This bases trust in BIOS
-starting at system reset and requires measurement of all code
-executed between system reset through the completion of the kernel
-boot as well as data objects used by that code.  In the case of a
-Linux kernel, this means all of BIOS, any option ROMs, the
-bootloader and the boot config.  In practice, this is a lot of
-code/data, much of which is subject to change from boot to boot
-(e.g. changing NICs may change option ROMs).  Without reference
-hashes, these measurement changes are difficult to assess or
-confirm as benign.  This process also does not provide DMA
-protection, memory configuration/alias checks and locks, crash
-protection, or policy support.
-
-By using the hardware-based root of trust that Intel TXT provides,
-many of these issues can be mitigated.  Specifically: many
-pre-launch components can be removed from the trust chain, DMA
-protection is provided to all launched components, a large number
-of platform configuration checks are performed and values locked,
-protection is provided for any data in the event of an improper
-shutdown, and there is support for policy-based execution/verification.
-This provides a more stable measurement and a higher assurance of
-system configuration and initial state than would be otherwise
-possible.  Since the tboot project is open source, source code for
-almost all parts of the trust chain is available (excepting SMM and
-Intel-provided firmware).
-
-How Does it Work?
-=
-
-o  Tboot is an executable that is launched by the bootloader as
-   the "kernel" (the binary the bootloader executes).
-o  It performs all of the work necessary to determine if the
-   platform supports Intel TXT and, if so, executes the GETSEC[SENTER]
-   processor instruction that initiates the dynamic root of trust.
-   -  If tboot determines that the system does not support Intel TXT
-  or is not conf

Re: [PATCH v3] n_tty: Fix buffer overruns with larger-than-4k pastes

[Stas Sergeev]

09.12.2013 21:10, Peter Hurley пишет:

On 12/09/2013 11:26 AM, Stas Sergeev wrote:

09.12.2013 18:50, Peter Hurley пишет:

  if (found && read_buf(ldata, eol) == __DISABLED_CHAR) {
  n--;
  eof_push = !n && ldata->read_tail != ldata->line_start;
+ldata->push = 0;
  }

Will this work if the last (and only) char written in raw
mode appear to be \0 (__DISABLED_CHAR)?


That would have triggered an EOF in older kernels so not a
regression.

I mean the case when icanon is enabled _after_ the
\0 was written. In an unpatched kernel it will not result
in an EOL mark, so I don't expect it to trigger EOF.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V4 07/10] powerpc, lib: Add new branch instruction analysis support functions

[Anshuman Khandual]

On 12/09/2013 11:51 AM, Michael Ellerman wrote:
> On Wed, 2013-04-12 at 10:32:39 UTC, Anshuman Khandual wrote:
>> Generic powerpc branch instruction analysis support added in the code
>> patching library which will help the subsequent patch on SW based
>> filtering of branch records in perf. This patch also converts and
>> exports some of the existing local static functions through the header
>> file to be used else where.
>>
>> diff --git a/arch/powerpc/include/asm/code-patching.h 
>> b/arch/powerpc/include/asm/code-patching.h
>> index a6f8c7a..8bab417 100644
>> --- a/arch/powerpc/include/asm/code-patching.h
>> +++ b/arch/powerpc/include/asm/code-patching.h
>> @@ -22,6 +22,36 @@
>>  #define BRANCH_SET_LINK 0x1
>>  #define BRANCH_ABSOLUTE 0x2
>>  
>> +#define XL_FORM_LR  0x4C20
>> +#define XL_FORM_CTR 0x4C000420
>> +#define XL_FORM_TAR 0x4C000460
>> +
>> +#define BO_ALWAYS0x0280
>> +#define BO_CTR   0x0200
>> +#define BO_CRBI_OFF  0x0080
>> +#define BO_CRBI_ON   0x0180
>> +#define BO_CRBI_HINT 0x0040
>> +
>> +/* Forms of branch instruction */
>> +int instr_is_branch_iform(unsigned int instr);
>> +int instr_is_branch_bform(unsigned int instr);
>> +int instr_is_branch_xlform(unsigned int instr);
>> +
>> +/* Classification of XL-form instruction */
>> +int is_xlform_lr(unsigned int instr);
>> +int is_xlform_ctr(unsigned int instr);
>> +int is_xlform_tar(unsigned int instr);
>> +
>> +/* Branch instruction is a call */
>> +int is_branch_link_set(unsigned int instr);
>> +
>> +/* BO field analysis (B-form or XL-form) */
>> +int is_bo_always(unsigned int instr);
>> +int is_bo_ctr(unsigned int instr);
>> +int is_bo_crbi_off(unsigned int instr);
>> +int is_bo_crbi_on(unsigned int instr);
>> +int is_bo_crbi_hint(unsigned int instr);
> 
> 
> I think this is the wrong API.
> 
> We end up with all these micro checks, which don't actually encapsulate much,
> and don't implement the logic perf needs. If we had another user for this 
> level
> of detail then it might make sense, but for a single user I think we're better
> off just implementing the semantics it wants.
> 

Having a comprehensive list of branch instruction analysis APIs which some other
user can also use in the future does not make it wrong. Being more elaborate and
detailed makes this one a better choice than the API you have suggested below.

> So that would be something more like:
> 
> bool instr_is_return_branch(unsigned int instr);
> bool instr_is_conditional_branch(unsigned int instr);
> bool instr_is_func_call(unsigned int instr);
> bool instr_is_indirect_func_call(unsigned int instr);
> 
> 
> These would then encapsulate something like the logic in your 8/10 patch. You
> can hopefully also optimise the checking logic in each routine because you 
> know
> the exact semantics you're implementing.

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

Re: [PATCH 3/6] regulator: fixed: use devm_regulator_register()

[Jingoo Han]

On Tuesday, December 10, 2013 2:45 AM, Mark Brown wrote:
> On Fri, Dec 06, 2013 at 04:09:29PM +0900, Jingoo Han wrote:
> > Use devm_regulator_register() to make cleanup paths simpler.
> 
> This has the same issue as the gpio regulator - it needs a more complete
> conversion to devm to be safe due to the use of other resources by the
> regulator while it's running.  The conversion looks straightfoward
> though.

OK, I see.
Please ignore this patch.
Thank you for your comment.

Best regards,
Jingoo Han

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

Re: [PATCH] perf tools: Fix bug for perf kvm report without guestmount.

[Dongsheng Yang]

On 12/10/2013 01:02 AM, David Ahern wrote:

On 12/10/13, 11:54 AM, Dongsheng Yang wrote:

Okey, David, I saw your commit 207b57926 (perf kvm: Fix regression with
guest machine creation) here. It is applied to fix a bug of SEGFAULT. I
have to say that it changed the behavior of report and lead to 
current bug.



Dongsheng, I appreciate your perseverance here. I am trying to survive 
this week due to a lot of demands on my time. Next week or the week 
after I will revisit your questions and comments on perf-kvm.


It is all right to me :).

Thanx !!

Yang


David
--
To unsubscribe from this list: send the line "unsubscribe 
linux-kernel" in

the body of a message to majord...@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/

[PATCH net V2 1/2] tun: unbreak truncated packet signalling

[Jason Wang]

Commit 6680ec68eff47d36f67b4351bc9836fd6cba9532
(tuntap: hardware vlan tx support) breaks the truncated packet signal by nev
return a length greater than iov length in tun_put_user(). This patch fixes
by always return the length of packet plus possible vlan header. Caller can
detect the truncated packet by comparing the return value and the size of io
length.

Cc: Zhi Yong Wu 
Cc: Michael S. Tsirkin 
Signed-off-by: Vlad Yasevich 
Signed-off-by: Jason Wang 
---
Changes from v1:
- increase total unconditionally
- do not move veth structure out of the vlan handing block
---
 drivers/net/tun.c | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index e26cbea..cd142134 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1184,7 +1184,7 @@ static ssize_t tun_put_user(struct tun_struct *tun,
 {
struct tun_pi pi = { 0, skb->protocol };
ssize_t total = 0;
-   int vlan_offset = 0;
+   int vlan_offset = 0, offset;
 
if (!(tun->flags & TUN_NO_PI)) {
if ((len -= sizeof(pi)) < 0)
@@ -1248,6 +1248,8 @@ static ssize_t tun_put_user(struct tun_struct *tun,
total += tun->vnet_hdr_sz;
}
 
+   offset = total;
+   total += skb->len;
if (!vlan_tx_tag_present(skb)) {
len = min_t(int, skb->len, len);
} else {
@@ -1262,24 +1264,24 @@ static ssize_t tun_put_user(struct tun_struct *tun,
 
vlan_offset = offsetof(struct vlan_ethhdr, h_vlan_proto);
len = min_t(int, skb->len + VLAN_HLEN, len);
+   total += VLAN_HLEN;
 
copy = min_t(int, vlan_offset, len);
-   ret = skb_copy_datagram_const_iovec(skb, 0, iv, total, copy);
+   ret = skb_copy_datagram_const_iovec(skb, 0, iv, offset, copy);
len -= copy;
-   total += copy;
+   offset += copy;
if (ret || !len)
goto done;
 
copy = min_t(int, sizeof(veth), len);
-   ret = memcpy_toiovecend(iv, (void *)&veth, total, copy);
+   ret = memcpy_toiovecend(iv, (void *)&veth, offset, copy);
len -= copy;
-   total += copy;
+   offset += copy;
if (ret || !len)
goto done;
}
 
-   skb_copy_datagram_const_iovec(skb, vlan_offset, iv, total, len);
-   total += len;
+   skb_copy_datagram_const_iovec(skb, vlan_offset, iv, offset, len);
 
 done:
tun->dev->stats.tx_packets++;
-- 
1.8.3.2

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

Re: [PATCH] devtmpfs: Calling delete_path() only when necessary

[Axel Lin]

2013/12/9 Axel Lin :
> 2013/12/9 Greg Kroah-Hartman :
>> On Mon, Dec 09, 2013 at 04:54:29PM +0800, Axel Lin wrote:
>>> 2013/12/9 Greg Kroah-Hartman :
>>> > On Wed, Dec 04, 2013 at 02:44:14PM +0800, Axel Lin wrote:
>>> >> 2013/12/4 Rob Landley :
>>> >> > On 11/16/2013 02:15:23 AM, Axel Lin wrote:
>>> >> >>
>>> >> >> The deleted variable is always 1 in current code.
>>> >> >> Initialize deleted variable to be 0, so delete_path() will be called 
>>> >> >> only
>>> >> >> when
>>> >> >> necessary.
>>> >> >>
>>> >> >> Signed-off-by: Axel Lin 
>>> >> >
>>> >> >
>>> >> > I'm not seeing this in linux-next, or a reply on the web archive. 
>>> >> > Assuming
>>> >> > nobody's objected to this, you might want to forward it to
>>> >> > triv...@kernel.org.
>>> >> >
>>> >> > That said, you could describe what it _does_ a little more?
>>> >>
>>> >> I was expecting Greg to pick up this patch.
>>> >>
>>> >> I thought the description is pretty clear.
>>> >> What the patch does is changing the init value of deleted variable to 0.
>>> >> The intention of this change is to avoid unnecessary delete_path() call.
>>> >
>>> > I agree the logic is a bit odd here, but are you seeing an "unnecessary"
>>> > delete_path() call happening?  The code has always been like this from
>>> > what I can tell...
>>>
>>> Honestly, I havn't see the "unnecessary" delete_path() call happening 
>>> druing my
>>> test. I look at the code when I was debugging a hangup issue.
>>> (In the end, I think the issue is not related to the devtmpfs code.)
>>> But I found the logic for the deleted variable looks odd.
>>> There are below possible (unlikely) case:
>>> When strchr(nodename, '/') != 0 and
>>> 1. If dentry->d_inode is NULL
>>> 2. vfs_getattr returns error
>>> 3. vfs_unlink returns error except -ENOENT.
>>>
>>> In these cases, delete_path() will fail anyway.
>>>
>>> Although this is a unlikely case, and I know the code is there since initial
>>> commit. But I think it's still good to fix it.
>>
>> Have you tested your patch to verify nothing breaks?
> Yes. I have this patch in my local build image since the day I sent the patch.
Hi Greg,
If you want more testing for this patch to ensure nothing break,
I think maybe Fengguang can also help to test it.

Hi, Fengguang
Can you help to add this patch to your test systems?
It's a one-line change, you can find the patch at
https://patchwork.kernel.org/patch/3192361/

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

Re: questions of cpuidle

[Alex Shi]

On 12/09/2013 11:26 PM, Preeti U Murthy wrote:
>> > If the cpu stopped the interrupt during deep c-state and without
>> > monitor/mwait support, which kind of ipi can wake the cpu? I mean like a
>> > x86 cpu, APIC stopped in c3 mode, but actually ipi send via apic bus. So
>> > I don't know which ipi work?
>> > 
> As far as my understanding goes, an external interrupt sent via the apic
> bus wakes up a core in deep idle state first,

Is there some evidence for this? Documents or some explanation?
 meaning powers on the core
> and hence the local apic. It does not yet acknowledge the interrupt,
> meaning it cannot invoke the interrupt handler immediately.
>After the core goes through some initialization steps after wakeup,
> it will be in a position to acknowledge the external interrupt and
> service it accordingly.
> 
> Ideally the interrupt handler of this external interrupt should be that
> of the local timer itself since it was meant to act on the behalf of the
> local timer interrupt.
> 

Added more Intel experts.

Many thanks for response, Preeti!

But I still don't know how to get external/internal interrupt by a deep
c-state cpu.
In Intel Architecture Software Developer's Manual Vol.3A, Figure 10-3.
Local APICs and I/O APIC When P6 Family Processors Are Used in
Multiple-Processor Systems.
The Local APIC is response for the the external/internal interrupt
receiving. and It is included in CPU.

And some explanation often be used in wikipedia.
(http://www.hardwaresecrets.com/article/Everything-You-Need-to-Know-About-the-CPU-C-States-Power-Saving-Modes/611/4)
It said the APIC clock was stopped in deep c-state, So I am wondering
how can the nonfunctional LAPIC pass interrupt to CPU?

And for monitor/mwait idle method, seems deep c-state cpu need to keep a
eye on memory bus. So seems the memory controller in cpu package is
impossible to get into sleep, right?
-- 
Thanks
Alex
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] dma: dw: Add suspend and resume handling for PCI mode DW_DMAC.

[Chew Chiau Ee]

From: Chew, Chiau Ee 

This is to disable/enable DW_DMAC hw during suspend/resume.

Signed-off-by: Chew, Chiau Ee 
Acked-by: Andy Shevchenko 
---
 drivers/dma/dw/pci.c |   33 +
 1 files changed, 33 insertions(+), 0 deletions(-)

diff --git a/drivers/dma/dw/pci.c b/drivers/dma/dw/pci.c
index e89fc24..97bc3a2 100644
--- a/drivers/dma/dw/pci.c
+++ b/drivers/dma/dw/pci.c
@@ -75,6 +75,36 @@ static void dw_pci_remove(struct pci_dev *pdev)
dev_warn(&pdev->dev, "can't remove device properly: %d\n", ret);
 }
 
+#ifdef CONFIG_PM_SLEEP
+
+static int dw_pci_suspend_noirq(struct device *dev)
+{
+   struct pci_dev *pci = to_pci_dev(dev);
+   struct dw_dma_chip *chip = pci_get_drvdata(pci);
+
+   return dw_dma_suspend(chip);
+};
+
+static int dw_pci_resume_noirq(struct device *dev)
+{
+   struct pci_dev *pci = to_pci_dev(dev);
+   struct dw_dma_chip *chip = pci_get_drvdata(pci);
+
+   return dw_dma_resume(chip);
+};
+
+#else /* !CONFIG_PM_SLEEP */
+
+#define dw_pci_suspend_noirq   NULL
+#define dw_pci_resume_noirqNULL
+
+#endif /* !CONFIG_PM_SLEEP */
+
+static const struct dev_pm_ops dw_pci_dev_pm_ops = {
+   .suspend_noirq = dw_pci_suspend_noirq,
+   .resume_noirq = dw_pci_resume_noirq,
+};
+
 static DEFINE_PCI_DEVICE_TABLE(dw_pci_id_table) = {
/* Medfield */
{ PCI_VDEVICE(INTEL, 0x0827), (kernel_ulong_t)&dw_pci_pdata },
@@ -92,6 +122,9 @@ static struct pci_driver dw_pci_driver = {
.id_table   = dw_pci_id_table,
.probe  = dw_pci_probe,
.remove = dw_pci_remove,
+   .driver = {
+   .pm = &dw_pci_dev_pm_ops,
+   },
 };
 
 module_pci_driver(dw_pci_driver);
-- 
1.7.4.4

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

Re: [PATCH] [SCSI] iscsi_boot_sysfs: Fix a memory leak in iscsi_boot_destroy_kset()

[Ethan Zhao]

Konrad,

 boot_kset was allocated when module loaded by
ibft_init()
  iscsi_boot_create_kset()
 kzalloc()

but wasn't freed when module unloaded by
ibft_exit()
   ibft_cleanup()
 iscsi_boot_destroy_kset()

Thanks,
Ethan

On Tue, Dec 10, 2013 at 5:30 AM, Konrad Rzeszutek Wilk
 wrote:
> On Mon, Dec 09, 2013 at 05:37:11PM +0800, Ethan Zhao wrote:
>> From: "Ethan Zhao" 
>>
>> Load and unload iscsi_ibft module will cause kernel memory leak, fix it
>> in scsi/iscsi_boot_sysfs.c iscsi_boot_destroy_kset().
>>
>
> Is there a stack trace?
>> Signed-off-by: Ethan Zhao 
>> ---
>>  drivers/scsi/iscsi_boot_sysfs.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/scsi/iscsi_boot_sysfs.c 
>> b/drivers/scsi/iscsi_boot_sysfs.c
>> index 14c1c8f..680bf6f 100644
>> --- a/drivers/scsi/iscsi_boot_sysfs.c
>> +++ b/drivers/scsi/iscsi_boot_sysfs.c
>> @@ -490,5 +490,6 @@ void iscsi_boot_destroy_kset(struct iscsi_boot_kset 
>> *boot_kset)
>>   iscsi_boot_remove_kobj(boot_kobj);
>>
>>   kset_unregister(boot_kset->kset);
>> + kfree(boot_kset);
>>  }
>>  EXPORT_SYMBOL_GPL(iscsi_boot_destroy_kset);
>> --
>> 1.8.3.4 (Apple Git-47)
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] perf tools: Fix bug for perf kvm report without guestmount.

[David Ahern]

On 12/10/13, 11:54 AM, Dongsheng Yang wrote:

Okey, David, I saw your commit 207b57926 (perf kvm: Fix regression with
guest machine creation) here. It is applied to fix a bug of SEGFAULT. I
have to say that it changed the behavior of report and lead to current bug.



Dongsheng, I appreciate your perseverance here. I am trying to survive 
this week due to a lot of demands on my time. Next week or the week 
after I will revisit your questions and comments on perf-kvm.


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

Re: [PATCH V4 08/10] powerpc, perf: Enable SW filtering in branch stack sampling framework

[Anshuman Khandual]

On 12/09/2013 11:51 AM, Michael Ellerman wrote:
> This code was already in need of some unindentation, and now it's just
> ridiculous.
> 
> To start with at the beginning of this routine we have:
> 
> while (..) {
>   if (!val)
>   break;
>   else {
>   // Bulk of the logic
>   ...
>   }
> }
> 
> That should almost always become:
> 
> while (..) {
>   if (!val)
>   break;
> 
>   // Bulk of the logic
>   ...
> }
> 
> 
> But in this case that's not enough. Please send a precursor patch which moves
> this logic out into a helper function.

Hey Michael,

I believe this patch should be able to take care of this.

commit d66d729715cabe0cfd8e34861a6afa8ad639ddf3
Author: Anshuman Khandual 
Date:   Tue Dec 10 11:10:06 2013 +0530

power, perf: Clean up BHRB processing

This patch cleans up some indentation problem and re-organizes the
BHRB processing code with an additional helper function.

Signed-off-by: Anshuman Khandual 

diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c
index 29b89e8..9ae96c5 100644
--- a/arch/powerpc/perf/core-book3s.c
+++ b/arch/powerpc/perf/core-book3s.c
@@ -400,11 +400,20 @@ static __u64 power_pmu_bhrb_to(u64 addr)
return target - (unsigned long)&instr + addr;
 }
 
+void update_branch_entry(struct cpu_hw_events *cpuhw, int u_index, u64 from, 
u64 to, int pred)
+{
+   cpuhw->bhrb_entries[u_index].from = from;
+   cpuhw->bhrb_entries[u_index].to = to;
+   cpuhw->bhrb_entries[u_index].mispred = pred;
+   cpuhw->bhrb_entries[u_index].predicted = ~pred;
+   return;
+}
+
 /* Processing BHRB entries */
 void power_pmu_bhrb_read(struct cpu_hw_events *cpuhw)
 {
u64 val;
-   u64 addr;
+   u64 addr, tmp;
int r_index, u_index, pred;
 
r_index = 0;
@@ -415,62 +424,54 @@ void power_pmu_bhrb_read(struct cpu_hw_events *cpuhw)
if (!val)
/* Terminal marker: End of valid BHRB entries */
break;
-   else {
-   addr = val & BHRB_EA;
-   pred = val & BHRB_PREDICTION;
 
-   if (!addr)
-   /* invalid entry */
-   continue;
+   addr = val & BHRB_EA;
+   pred = val & BHRB_PREDICTION;
 
-   /* Branches are read most recent first (ie. mfbhrb 0 is
-* the most recent branch).
-* There are two types of valid entries:
-* 1) a target entry which is the to address of a
-*computed goto like a blr,bctr,btar.  The next
-*entry read from the bhrb will be branch
-*corresponding to this target (ie. the actual
-*blr/bctr/btar instruction).
-* 2) a from address which is an actual branch.  If a
-*target entry proceeds this, then this is the
-*matching branch for that target.  If this is not
-*following a target entry, then this is a branch
-*where the target is given as an immediate field
-*in the instruction (ie. an i or b form branch).
-*In this case we need to read the instruction from
-*memory to determine the target/to address.
+   if (!addr)
+   /* invalid entry */
+   continue;
+
+   /* Branches are read most recent first (ie. mfbhrb 0 is
+* the most recent branch).
+* There are two types of valid entries:
+* 1) a target entry which is the to address of a
+*computed goto like a blr,bctr,btar.  The next
+*entry read from the bhrb will be branch
+*corresponding to this target (ie. the actual
+*blr/bctr/btar instruction).
+* 2) a from address which is an actual branch.  If a
+*target entry proceeds this, then this is the
+*matching branch for that target.  If this is not
+*following a target entry, then this is a branch
+*where the target is given as an immediate field
+*in the instruction (ie. an i or b form branch).
+*In this case we need to read the instruction from
+*memory to determine the target/to address.
+*/
+   if (val & BHRB_TARGET) {
+   /* Target branches use two entries
+* (ie. computed gotos/XL form)
 */
+   tmp = addr;
 
+   /* Ge

Re: [PATCH] perf tools: Fix bug for perf kvm report without guestmount.

[Dongsheng Yang]

NACK. Not needed and breaks the very intent of those 2 options.

David
--


Okey, David, I saw your commit 207b57926 (perf kvm: Fix regression with 
guest machine creation) here. It is applied to fix a bug of SEGFAULT. I 
have to say that it changed the behavior of report and lead to current bug.


commit 207b5792696206663a38e525b9793644895bad3b
Author: David Ahern 
Date:   Sun Jul 1 16:11:37 2012 -0600

perf kvm: Fix regression with guest machine creation


diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index c3e399b..56142d0 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -926,7 +926,7 @@ static struct machine *
else
pid = event->ip.pid;

-   return perf_session__find_machine(session, pid);
+   return perf_session__findnew_machine(session, pid);
}

return perf_session__find_host_machine(session);

In original, it uses perf_session__find_machine(), it means we deliver 
symbol to machine which has the same pid, if no machine found, deliver 
it to *default* guest. But if we use perf_session__findnew_machine() 
here, if no machine was found, new machine with pid will be built and 
added. Then the default guest which with pid == 0 will never get a 
symbol, right?


And because the new machine initialized here has no kernel map created, 
the symbol delivered to it will be marked as "unknown".


So, my patch here is to revert commit 207b57926 and fix the SEGFAULT bug 
in another way.


diff --git a/tools/perf/util/session.c b/tools/perf/util/session.c
index 8a7da6f..1770f2f 100644
--- a/tools/perf/util/session.c
+++ b/tools/perf/util/session.c
@@ -851,6 +851,7 @@ static struct machine *
   struct perf_sample *sample)
 {
const u8 cpumode = event->header.misc & 
PERF_RECORD_MISC_CPUMODE_MASK;

+   struct machine *machine;

if (perf_guest &&
((cpumode == PERF_RECORD_MISC_GUEST_KERNEL) ||
@@ -863,7 +864,11 @@ static struct machine *
else
pid = sample->pid;

-   return perf_session__findnew_machine(session, pid);
+   machine = perf_session__find_machine(session, pid);
+   if (!machine)
+   machine = perf_session__findnew_machine(session,
+ DEFAULT_GUEST_KERNEL_ID);
+   return machine;
}

return &session->machines.host;

If there is a machine for this event or sample, return this machine. If 
no, return *default* guest.


About the SEGFAULT bug you mentioned, it is solved by if (!machine).

Please correct me if I am wrong, thanx !!

- Yang

To unsubscribe from this list: send the line "unsubscribe 
linux-kernel" in

the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/



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

RE: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU)

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

> -Original Message-
> From: Alex Williamson [mailto:alex.william...@redhat.com]
> Sent: Saturday, December 07, 2013 1:00 AM
> To: Wood Scott-B07421
> Cc: Bhushan Bharat-R65777; linux-...@vger.kernel.org; ag...@suse.de; Yoder
> Stuart-B08248; io...@lists.linux-foundation.org; bhelg...@google.com; 
> linuxppc-
> d...@lists.ozlabs.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU)
> 
> On Fri, 2013-12-06 at 12:59 -0600, Scott Wood wrote:
> > On Thu, 2013-12-05 at 22:11 -0600, Bharat Bhushan wrote:
> > >
> > > > -Original Message-
> > > > From: Wood Scott-B07421
> > > > Sent: Friday, December 06, 2013 5:52 AM
> > > > To: Bhushan Bharat-R65777
> > > > Cc: Alex Williamson; linux-...@vger.kernel.org; ag...@suse.de;
> > > > Yoder Stuart- B08248; io...@lists.linux-foundation.org;
> > > > bhelg...@google.com; linuxppc- d...@lists.ozlabs.org;
> > > > linux-kernel@vger.kernel.org
> > > > Subject: Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale
> > > > IOMMU (PAMU)
> > > >
> > > > On Thu, 2013-11-28 at 03:19 -0600, Bharat Bhushan wrote:
> > > > >
> > > > > > -Original Message-
> > > > > > From: Bhushan Bharat-R65777
> > > > > > Sent: Wednesday, November 27, 2013 9:39 PM
> > > > > > To: 'Alex Williamson'
> > > > > > Cc: Wood Scott-B07421; linux-...@vger.kernel.org;
> > > > > > ag...@suse.de; Yoder Stuart- B08248;
> > > > > > io...@lists.linux-foundation.org; bhelg...@google.com;
> > > > > > linuxppc- d...@lists.ozlabs.org; linux-kernel@vger.kernel.org
> > > > > > Subject: RE: [PATCH 0/9 v2] vfio-pci: add support for
> > > > > > Freescale IOMMU (PAMU)
> > > > > >
> > > > > > If we just provide the size of MSI bank to userspace then
> > > > > > userspace cannot do anything wrong.
> > > > >
> > > > > So userspace does not know address, so it cannot mmap and cause
> > > > > any
> > > > interference by directly reading/writing.
> > > >
> > > > That's security through obscurity...  Couldn't the malicious user
> > > > find out the address via other means, such as experimentation on
> > > > another system over which they have full control?  What would
> > > > happen if the user reads from their device's PCI config space?  Or
> > > > gets the information via some back door in the PCI device they
> > > > own?  Or pokes throughout the address space looking for something that
> generates an interrupt to its own device?
> > >
> > > So how to solve this problem, Any suggestion ?
> > >
> > > We have to map one window in PAMU for MSIs and a malicious user can
> > > ask its device to do DMA to MSI window region with any pair of
> > > address and data, which can lead to unexpected MSIs in system?
> >
> > I don't think there are any solutions other than to limit each bank to
> > one user, unless the admin turns some knob that says they're OK with
> > the partial loss of isolation.
> 
> Even if the admin does opt-in to an allow_unsafe_interrupts options, it should
> still be reasonably difficult for one guest to interfere with the other.  I
> don't think we want to rely on the blind luck of making the full MSI bank
> accessible to multiple guests and hoping they don't step on each other.

Not sure how to solve in this case (sharing MSI page)

>  That probably means that vfio needs to manage the space rather than the 
> guest.

What you mean by " vfio needs to manage the space rather than the guest"?

Thanks
-Bharat

> Thanks,
> 
> Alex
> 

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

Re: [PATCH] usb-storage: scsiglue: Changing the command result

[Greg KH]

On Tue, Dec 10, 2013 at 10:53:59AM +0530, Vishal Annapurve wrote:
> Hi Greg,
> 
> Does this look fine? I will send over other patches
> once you confirm.

I'm not going to confirm a broken format...

Please go read the file I pointed you at as to how to properly do
this.

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 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU)

[Alex Williamson]

On Tue, 2013-12-10 at 05:37 +, bharat.bhus...@freescale.com wrote:
> 
> > -Original Message-
> > From: Alex Williamson [mailto:alex.william...@redhat.com]
> > Sent: Saturday, December 07, 2013 1:00 AM
> > To: Wood Scott-B07421
> > Cc: Bhushan Bharat-R65777; linux-...@vger.kernel.org; ag...@suse.de; Yoder
> > Stuart-B08248; io...@lists.linux-foundation.org; bhelg...@google.com; 
> > linuxppc-
> > d...@lists.ozlabs.org; linux-kernel@vger.kernel.org
> > Subject: Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale IOMMU (PAMU)
> > 
> > On Fri, 2013-12-06 at 12:59 -0600, Scott Wood wrote:
> > > On Thu, 2013-12-05 at 22:11 -0600, Bharat Bhushan wrote:
> > > >
> > > > > -Original Message-
> > > > > From: Wood Scott-B07421
> > > > > Sent: Friday, December 06, 2013 5:52 AM
> > > > > To: Bhushan Bharat-R65777
> > > > > Cc: Alex Williamson; linux-...@vger.kernel.org; ag...@suse.de;
> > > > > Yoder Stuart- B08248; io...@lists.linux-foundation.org;
> > > > > bhelg...@google.com; linuxppc- d...@lists.ozlabs.org;
> > > > > linux-kernel@vger.kernel.org
> > > > > Subject: Re: [PATCH 0/9 v2] vfio-pci: add support for Freescale
> > > > > IOMMU (PAMU)
> > > > >
> > > > > On Thu, 2013-11-28 at 03:19 -0600, Bharat Bhushan wrote:
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Bhushan Bharat-R65777
> > > > > > > Sent: Wednesday, November 27, 2013 9:39 PM
> > > > > > > To: 'Alex Williamson'
> > > > > > > Cc: Wood Scott-B07421; linux-...@vger.kernel.org;
> > > > > > > ag...@suse.de; Yoder Stuart- B08248;
> > > > > > > io...@lists.linux-foundation.org; bhelg...@google.com;
> > > > > > > linuxppc- d...@lists.ozlabs.org; linux-kernel@vger.kernel.org
> > > > > > > Subject: RE: [PATCH 0/9 v2] vfio-pci: add support for
> > > > > > > Freescale IOMMU (PAMU)
> > > > > > >
> > > > > > > If we just provide the size of MSI bank to userspace then
> > > > > > > userspace cannot do anything wrong.
> > > > > >
> > > > > > So userspace does not know address, so it cannot mmap and cause
> > > > > > any
> > > > > interference by directly reading/writing.
> > > > >
> > > > > That's security through obscurity...  Couldn't the malicious user
> > > > > find out the address via other means, such as experimentation on
> > > > > another system over which they have full control?  What would
> > > > > happen if the user reads from their device's PCI config space?  Or
> > > > > gets the information via some back door in the PCI device they
> > > > > own?  Or pokes throughout the address space looking for something that
> > generates an interrupt to its own device?
> > > >
> > > > So how to solve this problem, Any suggestion ?
> > > >
> > > > We have to map one window in PAMU for MSIs and a malicious user can
> > > > ask its device to do DMA to MSI window region with any pair of
> > > > address and data, which can lead to unexpected MSIs in system?
> > >
> > > I don't think there are any solutions other than to limit each bank to
> > > one user, unless the admin turns some knob that says they're OK with
> > > the partial loss of isolation.
> > 
> > Even if the admin does opt-in to an allow_unsafe_interrupts options, it 
> > should
> > still be reasonably difficult for one guest to interfere with the other.  I
> > don't think we want to rely on the blind luck of making the full MSI bank
> > accessible to multiple guests and hoping they don't step on each other.
> 
> Not sure how to solve in this case (sharing MSI page)
> 
> >  That probably means that vfio needs to manage the space rather than the 
> > guest.
> 
> What you mean by " vfio needs to manage the space rather than the guest"?

I mean there needs to be some kernel component managing the contents of
the MSI page rather than just handing it out to the user and hoping for
the best.  The user API also needs to remain the same whether the user
has the MSI page exclusively or it's shared with others (kernel or
users).  Thanks,

Alex

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

[PATCH net V2 2/2] macvtap: signal truncated packets

[Jason Wang]

macvtap_put_user() never return a value grater than iov length, this in fact
bypasses the truncated checking in macvtap_recvmsg(). Fix this by always
returning the size of packet plus the possible vlan header to let the trunca
checking work.

Cc: Vlad Yasevich 
Cc: Zhi Yong Wu 
Cc: Michael S. Tsirkin 
Signed-off-by: Jason Wang 
---
Changes from v1:
- increase total unconditionally
- do not move the structure veth out of the vlan handling block
---
 drivers/net/macvtap.c | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 957cc5c..ded4b2c 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -770,7 +770,7 @@ static ssize_t macvtap_put_user(struct macvtap_queue *q,
int ret;
int vnet_hdr_len = 0;
int vlan_offset = 0;
-   int copied;
+   int copied, offset;
 
if (q->flags & IFF_VNET_HDR) {
struct virtio_net_hdr vnet_hdr;
@@ -785,7 +785,8 @@ static ssize_t macvtap_put_user(struct macvtap_queue *q,
if (memcpy_toiovecend(iv, (void *)&vnet_hdr, 0, 
sizeof(vnet_hdr)))
return -EFAULT;
}
-   copied = vnet_hdr_len;
+   offset = copied = vnet_hdr_len;
+   copied += skb->len;
 
if (!vlan_tx_tag_present(skb))
len = min_t(int, skb->len, len);
@@ -800,24 +801,24 @@ static ssize_t macvtap_put_user(struct macvtap_queue *q,
 
vlan_offset = offsetof(struct vlan_ethhdr, h_vlan_proto);
len = min_t(int, skb->len + VLAN_HLEN, len);
+   copied += VLAN_HLEN;
 
copy = min_t(int, vlan_offset, len);
-   ret = skb_copy_datagram_const_iovec(skb, 0, iv, copied, copy);
+   ret = skb_copy_datagram_const_iovec(skb, 0, iv, offset, copy);
len -= copy;
-   copied += copy;
+   offset += copy;
if (ret || !len)
goto done;
 
copy = min_t(int, sizeof(veth), len);
-   ret = memcpy_toiovecend(iv, (void *)&veth, copied, copy);
+   ret = memcpy_toiovecend(iv, (void *)&veth, offset, copy);
len -= copy;
-   copied += copy;
+   offset += copy;
if (ret || !len)
goto done;
}
 
-   ret = skb_copy_datagram_const_iovec(skb, vlan_offset, iv, copied, len);
-   copied += len;
+   ret = skb_copy_datagram_const_iovec(skb, vlan_offset, iv, offset, len);
 
 done:
return ret ? ret : copied;
@@ -875,7 +876,7 @@ static ssize_t macvtap_aio_read(struct kiocb *iocb, const 
struct iovec *iv,
}
 
ret = macvtap_do_read(q, iocb, iv, len, file->f_flags & O_NONBLOCK);
-   ret = min_t(ssize_t, ret, len); /* XXX copied from tun.c. Why? */
+   ret = min_t(ssize_t, ret, len);
if (ret > 0)
iocb->ki_pos = ret;
 out:
-- 
1.8.3.2

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

Re:HDPE LDPE PET

[Iris]

Dear Sir,

Good day!

We had dealing plastic raw materials for many years . And supplied high quality 
different grade HDPE/LDPE/PP/PET to our old and new customers.
  
Should any of the items be of interest to you, please let me know. We shall be 
glad to give you our lowest quotations upon receipt of your detailed 
requirements.

Thanks,
Iris
Email: iris20111...@hotmail.com
Skype:iris.song12

Re: [PATCH net 2/2] macvtap: signal truncated packets

[Jason Wang]

On 12/09/2013 07:02 PM, Michael S. Tsirkin wrote:
> On Mon, Dec 09, 2013 at 06:25:17PM +0800, Jason Wang wrote:
>> macvtap_put_user() never return a value grater than iov length, this in fact
>> bypasses the truncated checking in macvtap_recvmsg(). Fix this by always
>> returning the size of packet plus the possible vlan header to let the 
>> truncated
>> checking work.
>>
>> Cc: Vlad Yasevich 
>> Cc: Zhi Yong Wu 
>> Signed-off-by: Jason Wang 
> Same comments as for tun really, but here it's also
> kind of ugly to call a variable copied if we don't copy.
>
> Also, maybe we should name the variable "copied" for tun,
> this would make the code more similar.

Agree, but better with a separate patch for net-next.
>> ---
>> The patch is needed for stable.
>> ---
>>  drivers/net/macvtap.c | 27 ++-
>>  1 file changed, 14 insertions(+), 13 deletions(-)
>>
>> diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
>> index 957cc5c..7544a0c 100644
>> --- a/drivers/net/macvtap.c
>> +++ b/drivers/net/macvtap.c
>> @@ -767,10 +767,14 @@ static ssize_t macvtap_put_user(struct macvtap_queue 
>> *q,
>>  const struct sk_buff *skb,
>>  const struct iovec *iv, int len)
>>  {
>> -int ret;
>> +int ret, off;
>>  int vnet_hdr_len = 0;
>>  int vlan_offset = 0;
>>  int copied;
>> +struct {
>> +__be16 h_vlan_proto;
>> +__be16 h_vlan_TCI;
>> +} veth;
>>  
>>  if (q->flags & IFF_VNET_HDR) {
>>  struct virtio_net_hdr vnet_hdr;
>> @@ -785,16 +789,13 @@ static ssize_t macvtap_put_user(struct macvtap_queue 
>> *q,
>>  if (memcpy_toiovecend(iv, (void *)&vnet_hdr, 0, 
>> sizeof(vnet_hdr)))
>>  return -EFAULT;
>>  }
>> -copied = vnet_hdr_len;
>> +off = copied = vnet_hdr_len;
>>  
>>  if (!vlan_tx_tag_present(skb))
>>  len = min_t(int, skb->len, len);
>>  else {
>>  int copy;
>> -struct {
>> -__be16 h_vlan_proto;
>> -__be16 h_vlan_TCI;
>> -} veth;
>> +
>>  veth.h_vlan_proto = skb->vlan_proto;
>>  veth.h_vlan_TCI = htons(vlan_tx_tag_get(skb));
>>  
>> @@ -802,22 +803,22 @@ static ssize_t macvtap_put_user(struct macvtap_queue 
>> *q,
>>  len = min_t(int, skb->len + VLAN_HLEN, len);
>>  
>>  copy = min_t(int, vlan_offset, len);
>> -ret = skb_copy_datagram_const_iovec(skb, 0, iv, copied, copy);
>> +ret = skb_copy_datagram_const_iovec(skb, 0, iv, off, copy);
>>  len -= copy;
>> -copied += copy;
>> +off += copy;
>>  if (ret || !len)
>>  goto done;
>>  
>>  copy = min_t(int, sizeof(veth), len);
>> -ret = memcpy_toiovecend(iv, (void *)&veth, copied, copy);
>> +ret = memcpy_toiovecend(iv, (void *)&veth, off, copy);
>>  len -= copy;
>> -copied += copy;
>> +off += copy;
>>  if (ret || !len)
>>  goto done;
>>  }
>>  
>> -ret = skb_copy_datagram_const_iovec(skb, vlan_offset, iv, copied, len);
>> -copied += len;
>> +ret = skb_copy_datagram_const_iovec(skb, vlan_offset, iv, off, len);
>> +copied += skb->len + (vlan_offset ? sizeof(veth) : 0);
>>  
>>  done:
>>  return ret ? ret : copied;
>> @@ -875,7 +876,7 @@ static ssize_t macvtap_aio_read(struct kiocb *iocb, 
>> const struct iovec *iv,
>>  }
>>  
>>  ret = macvtap_do_read(q, iocb, iv, len, file->f_flags & O_NONBLOCK);
>> -ret = min_t(ssize_t, ret, len); /* XXX copied from tun.c. Why? */
>> +ret = min_t(ssize_t, ret, len);
>>  if (ret > 0)
>>  iocb->ki_pos = ret;
>>  out:
>
>
>> -- 
>> 1.8.3.2
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

Re: [PATCH net 1/2] tun: unbreak truncated packet signalling

[Jason Wang]

On 12/09/2013 11:31 PM, Vlad Yasevich wrote:
> On 12/09/2013 05:55 AM, Michael S. Tsirkin wrote:
>> On Mon, Dec 09, 2013 at 06:25:16PM +0800, Jason Wang wrote:
>>> Commit 6680ec68eff47d36f67b4351bc9836fd6cba9532
>>> (tuntap: hardware vlan tx support) breaks the truncated packet signal
> by never
>>> return a length greater than iov length in tun_put_user(). This patch
> fixes this
>>> by always return the length of packet plus possible vlan header.
> Caller can
>>> detect the truncated packet by comparing the return value and the
> size of iov
>>> length.
>>>
>>> Reported-by: Vlad Yasevich 
>>> Cc: Vlad Yasevich 
>>> Cc: Zhi Yong Wu 
>>> Signed-off-by: Jason Wang 
>> So writer gets back a value greater than what was written?
>>
>>> ---
>>> The patch is needed for stable.
>>> ---
>>>  drivers/net/tun.c | 23 ---
>>>  1 file changed, 12 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>>> index e26cbea..dd1bd7a 100644
>>> --- a/drivers/net/tun.c
>>> +++ b/drivers/net/tun.c
>>> @@ -1183,7 +1183,11 @@ static ssize_t tun_put_user(struct tun_struct
> *tun,
>>> const struct iovec *iv, int len)
>>>  {
>>> struct tun_pi pi = { 0, skb->protocol };
>>> -   ssize_t total = 0;
>>> +   struct {
>>> +   __be16 h_vlan_proto;
>>> +   __be16 h_vlan_TCI;
>>> +   } veth;
>>> +   ssize_t total = 0, off = 0;
>> Why off = 0 here?
>> We initialize it to total unconditionally, don't we?
>>
>>> int vlan_offset = 0;
>>>
>>> if (!(tun->flags & TUN_NO_PI)) {
>>> @@ -1248,14 +1252,11 @@ static ssize_t tun_put_user(struct tun_struct
> *tun,
>>> total += tun->vnet_hdr_sz;
>>> }
>>>
>>> +   off = total;
>>> if (!vlan_tx_tag_present(skb)) {
>>> len = min_t(int, skb->len, len);
>>> } else {
>>> int copy, ret;
>>> -   struct {
>>> -   __be16 h_vlan_proto;
>>> -   __be16 h_vlan_TCI;
>>> -   } veth;
>>>
>>> veth.h_vlan_proto = skb->vlan_proto;
>>> veth.h_vlan_TCI = htons(vlan_tx_tag_get(skb));
>>> @@ -1264,22 +1265,22 @@ static ssize_t tun_put_user(struct tun_struct
> *tun,
>>> len = min_t(int, skb->len + VLAN_HLEN, len);
>>>
>>> copy = min_t(int, vlan_offset, len);
>>> -   ret = skb_copy_datagram_const_iovec(skb, 0, iv, total, copy);
>>> +   ret = skb_copy_datagram_const_iovec(skb, 0, iv, off, copy);
>>> len -= copy;
>>> -   total += copy;
>>> +   off += copy;
>>> if (ret || !len)
>>> goto done;
>>>
>>> copy = min_t(int, sizeof(veth), len);
>>> -   ret = memcpy_toiovecend(iv, (void *)&veth, total, copy);
>>> +   ret = memcpy_toiovecend(iv, (void *)&veth, off, copy);
>>> len -= copy;
>>> -   total += copy;
>>> +   off += copy;
>>> if (ret || !len)
>>> goto done;
>> This seems wrong: if one of the branches above is taken, total is
>> never incremented.
>>
>>> }
>>>
>>> -   skb_copy_datagram_const_iovec(skb, vlan_offset, iv, total, len);
>>> -   total += len;
>>> +   skb_copy_datagram_const_iovec(skb, vlan_offset, iv, off, len);
>>> +   total += skb->len + (vlan_offset ? sizeof(veth) : 0);
>>>
>>>  done:
>>> tun->dev->stats.tx_packets++;
>> I also think it's inelegant that the veth struct is now in the
>> outside scope, and the extra ? is also ugly.
>>
>> Here's a smaller patch to fix all these problems - what do you think?
>>
>>
>>
>> Signed-off-by: Michael S. Tsirkin 
>>
>> ---
>>
>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>> index 782e38b..3297e41 100644
>> --- a/drivers/net/tun.c
>> +++ b/drivers/net/tun.c
>> @@ -1183,7 +1183,7 @@ static ssize_t tun_put_user(struct tun_struct *tun,
>>  const struct iovec *iv, int len)
>>  {
>>  struct tun_pi pi = { 0, skb->protocol };
>> -ssize_t total = 0;
>> +ssize_t total = 0, offset;
>>  int vlan_offset = 0;
>>
>>  if (!(tun->flags & TUN_NO_PI)) {
>> @@ -1248,6 +1248,8 @@ static ssize_t tun_put_user(struct tun_struct *tun,
>>  total += tun->vnet_hdr_sz;
>>  }
>>
>> +offset = total;
>> +total += skb->len;
>>  if (!vlan_tx_tag_present(skb)) {
>>  len = min_t(int, skb->len, len);
>>  } else {
>> @@ -1257,6 +1259,8 @@ static ssize_t tun_put_user(struct tun_struct *tun,
>>  __be16 h_vlan_TCI;
>>  } veth;
>>
>> +total += sizeof(veth);
>> +
>>  veth.h_vlan_proto = skb->vlan_proto;
>>  veth.h_vlan_TCI = htons(vlan_tx_tag_get(skb));
>>
>> @@ -1279,7 +1283,6 @@ static ssize_t tun_put_user(struct tun_struct *tun,
>>  }
>>
>>  skb_copy_datagram_const_iovec(skb, vlan_offset, iv, total, len);
>> -total += len;
>>
>>  done:
>>  tun->dev->stats.tx_packets++;
>>
>
> You have to use 'offset' instead of 'total' when doing s

Re: [PATCH net 1/2] tun: unbreak truncated packet signalling

[Jason Wang]

On 12/09/2013 06:56 PM, Michael S. Tsirkin wrote:
> On Mon, Dec 09, 2013 at 12:55:29PM +0200, Michael S. Tsirkin wrote:
>> On Mon, Dec 09, 2013 at 06:25:16PM +0800, Jason Wang wrote:
>>> Commit 6680ec68eff47d36f67b4351bc9836fd6cba9532
>>> (tuntap: hardware vlan tx support) breaks the truncated packet signal by 
>>> never
>>> return a length greater than iov length in tun_put_user(). This patch fixes 
>>> this
>>> by always return the length of packet plus possible vlan header. Caller can
>>> detect the truncated packet by comparing the return value and the size of 
>>> iov
>>> length.
>>>
>>> Reported-by: Vlad Yasevich 
>>> Cc: Vlad Yasevich 
>>> Cc: Zhi Yong Wu 
>>> Signed-off-by: Jason Wang 
>> So writer gets back a value greater than what was written?
> Pls ignore this question - wrote it before I understood the
> patch, and forgot to remove.
> The rest of the comments and the proposed alternative patch
> still stand.
>
>>> ---
>>> The patch is needed for stable.
>>> ---
>>>  drivers/net/tun.c | 23 ---
>>>  1 file changed, 12 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>>> index e26cbea..dd1bd7a 100644
>>> --- a/drivers/net/tun.c
>>> +++ b/drivers/net/tun.c
>>> @@ -1183,7 +1183,11 @@ static ssize_t tun_put_user(struct tun_struct *tun,
>>> const struct iovec *iv, int len)
>>>  {
>>> struct tun_pi pi = { 0, skb->protocol };
>>> -   ssize_t total = 0;
>>> +   struct {
>>> +   __be16 h_vlan_proto;
>>> +   __be16 h_vlan_TCI;
>>> +   } veth;
>>> +   ssize_t total = 0, off = 0;
>> Why off = 0 here?
>> We initialize it to total unconditionally, don't we?

True, it's useless.
>>> int vlan_offset = 0;
>>>  
>>> if (!(tun->flags & TUN_NO_PI)) {
>>> @@ -1248,14 +1252,11 @@ static ssize_t tun_put_user(struct tun_struct *tun,
>>> total += tun->vnet_hdr_sz;
>>> }
>>>  
>>> +   off = total;
>>> if (!vlan_tx_tag_present(skb)) {
>>> len = min_t(int, skb->len, len);
>>> } else {
>>> int copy, ret;
>>> -   struct {
>>> -   __be16 h_vlan_proto;
>>> -   __be16 h_vlan_TCI;
>>> -   } veth;
>>>  
>>> veth.h_vlan_proto = skb->vlan_proto;
>>> veth.h_vlan_TCI = htons(vlan_tx_tag_get(skb));
>>> @@ -1264,22 +1265,22 @@ static ssize_t tun_put_user(struct tun_struct *tun,
>>> len = min_t(int, skb->len + VLAN_HLEN, len);
>>>  
>>> copy = min_t(int, vlan_offset, len);
>>> -   ret = skb_copy_datagram_const_iovec(skb, 0, iv, total, copy);
>>> +   ret = skb_copy_datagram_const_iovec(skb, 0, iv, off, copy);
>>> len -= copy;
>>> -   total += copy;
>>> +   off += copy;
>>> if (ret || !len)
>>> goto done;
>>>  
>>> copy = min_t(int, sizeof(veth), len);
>>> -   ret = memcpy_toiovecend(iv, (void *)&veth, total, copy);
>>> +   ret = memcpy_toiovecend(iv, (void *)&veth, off, copy);
>>> len -= copy;
>>> -   total += copy;
>>> +   off += copy;
>>> if (ret || !len)
>>> goto done;
>> This seems wrong: if one of the branches above is taken, total is
>> never incremented.

Right.
>>> }
>>>  
>>> -   skb_copy_datagram_const_iovec(skb, vlan_offset, iv, total, len);
>>> -   total += len;
>>> +   skb_copy_datagram_const_iovec(skb, vlan_offset, iv, off, len);
>>> +   total += skb->len + (vlan_offset ? sizeof(veth) : 0);
>>>  
>>>  done:
>>> tun->dev->stats.tx_packets++;
>> I also think it's inelegant that the veth struct is now in the
>> outside scope, and the extra ? is also ugly.
>>
>> Here's a smaller patch to fix all these problems - what do you think?
>>
>>
>>
>> Signed-off-by: Michael S. Tsirkin 
>>
>> ---
>>
>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>> index 782e38b..3297e41 100644
>> --- a/drivers/net/tun.c
>> +++ b/drivers/net/tun.c
>> @@ -1183,7 +1183,7 @@ static ssize_t tun_put_user(struct tun_struct *tun,
>>  const struct iovec *iv, int len)
>>  {
>>  struct tun_pi pi = { 0, skb->protocol };
>> -ssize_t total = 0;
>> +ssize_t total = 0, offset;
>>  int vlan_offset = 0;
>>  
>>  if (!(tun->flags & TUN_NO_PI)) {
>> @@ -1248,6 +1248,8 @@ static ssize_t tun_put_user(struct tun_struct *tun,
>>  total += tun->vnet_hdr_sz;
>>  }
>>  
>> +offset = total;
>> +total += skb->len;
>>  if (!vlan_tx_tag_present(skb)) {
>>  len = min_t(int, skb->len, len);
>>  } else {
>> @@ -1257,6 +1259,8 @@ static ssize_t tun_put_user(struct tun_struct *tun,
>>  __be16 h_vlan_TCI;
>>  } veth;
>>  
>> +total += sizeof(veth);
>> +
>>  veth.h_vlan_proto = skb->vlan_proto;
>>  veth.h_vlan_TCI = htons(vlan_tx_tag_get(skb));
>>  
>> @@ -1279,7 +1283,6 @@ static ssize_t tun_put_user(struct t

Re: [git pull] Please pull powerpc.git merge branch

[Benjamin Herrenschmidt]

On Mon, 2013-12-09 at 19:58 -0800, Linus Torvalds wrote:
> On Mon, Dec 9, 2013 at 5:57 PM, Benjamin Herrenschmidt
>  wrote:
> >
> > Here are a handful of powerpc fixes for 3.13.
> 
> Grr.
> 
> I've pulled it, but looking at that history, it's just pure and utter
> f*cking garbage.
> 
> It was rebased *minutes* before sending it, as far as I can tell. Why?

It was *created* shortly before sending it:

Basically I put that thing together as a patchwork bundle which I grew
over this week.

Today I just applied them to my git, ran my build testers, booted a
machine to dbl check and sent. I tend to not let things linger long in
git when it's just fixes like that.

> And it has a pointless merge that you must have created with "--no-ff"
> for no apparent good reason.

Oh that's my fault. I thought you preferred that way to keep track of
cases where I pull from somebody since then the patch don't have my
s-o-b... my bad for misunderstanding that part of the process.

> WTF? What the hell happened here, and why? As mentioned, it's in my
> tree, but I was *this* close to just unpulling and saying "fuck that"
> when I started looking at it.

Heh sorry.

Cheers,
Ben.

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


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] ASoC: fsl: imx-wm8962: Grant hw_params/free() permission to control FLL

[Nicolin Chen]

On Mon, Dec 09, 2013 at 05:56:40PM +, Mark Brown wrote:
> On Fri, Dec 06, 2013 at 11:38:29PM +0800, Nicolin Chen wrote:
> 
> > +static int imx_hifi_hw_free(struct snd_pcm_substream *substream)
> > +{
> > +   struct snd_soc_pcm_runtime *rtd = substream->private_data;
> > +   struct snd_soc_dai *codec_dai = rtd->codec_dai;
> > +
> > +   /* Don't diable FLL if still having multiple substreams running */
> > +   if (codec_dai->active != 1)
> > +   return 0;
> > +
> > +   return imx_wm8962_disable_fll(codec_dai);
> 
> This will still disable the FLL if there's an analogue bypass path
> active.  I'd suggest changing enable() and disable() to reference count.

I was expecting this would disable it for further reconfiguration. But it
seems I should also considerate the case using bypass path and normal PCM
playback simultaneously, which looks a bit complex.

> 
> > +   if (dapm->bias_level == SND_SOC_BIAS_STANDBY)
> > +   return imx_wm8962_enable_fll(codec_dai, 44100,
> > +   SNDRV_PCM_FORMAT_S16_LE);
> 
> It might be slightly nicer to keep the static variable for the frequency
> - that way if we start up due to set_bias_level() we'll keep the last
> rate played which might be more likely to avoid locking playbacks out.
> Very minor thing though, I wouldn't worry about it.

I'd like to follow this way.

Thank you,
Nicolin Chen

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

Re: [PATCH 18/20] audit: add new message type AUDIT_CREATE_NS

[Gao feng]

On 12/10/2013 01:53 AM, Serge Hallyn wrote:
> Quoting Gao feng (gaof...@cn.fujitsu.com):
>> On 12/07/2013 06:10 AM, Serge E. Hallyn wrote:
>>> Quoting Gao feng (gaof...@cn.fujitsu.com):
 Since there is no more place for flags of clone system call.
 we need to find a way to create audit namespace.

 this patch add a new type of message AUDIT_CREATE_NS.
 user space can create new audit namespace through
 netlink.

 Right now, The privileged user in user namespace is allowed
 to create audit namespace. it means the unprivileged user can
 create an user namespace and then create audit namespace.

 Looks like it is not safe, but even the unprivileged user can
 create audit namespace, it can do no harm to the host. un-init
 audit namespace cann't effect the host.

 In the follow patches, the audit_backlog_limit will be per
 audit namesapace, but only the privileged user has rights to
 modify it. and the default value of audit_backlog_limit for
 uninit audit namespace will be set to 0.

 And the audit_rate_limit will be limited too.

 Signed-off-by: Gao feng 
 ---
  include/linux/audit_namespace.h |  7 +++
  include/uapi/linux/audit.h  |  1 +
  kernel/audit.c  | 22 ++
  kernel/audit_namespace.c| 29 +
  4 files changed, 59 insertions(+)

 diff --git a/include/linux/audit_namespace.h 
 b/include/linux/audit_namespace.h
 index 79a9b78..b17f052 100644
 --- a/include/linux/audit_namespace.h
 +++ b/include/linux/audit_namespace.h
 @@ -54,6 +54,8 @@ void put_audit_ns(struct audit_namespace *ns)
rcu_read_unlock();
}
  }
 +
 +extern int unshare_audit_namespace(void);
  #else
  static inline
  struct audit_namespace *get_audit_ns(struct audit_namespace *ns)
 @@ -66,6 +68,11 @@ void put_audit_ns(struct audit_namespace *ns)
  {
  
  }
 +
 +static inline int unshare_audit_namespace()
 +{
 +  return -EINVAL;
 +}
  #endif
  
  static inline struct
 diff --git a/include/uapi/linux/audit.h b/include/uapi/linux/audit.h
 index 75cef3f..877d509 100644
 --- a/include/uapi/linux/audit.h
 +++ b/include/uapi/linux/audit.h
 @@ -68,6 +68,7 @@
  #define AUDIT_MAKE_EQUIV  1015/* Append to watched tree */
  #define AUDIT_TTY_GET 1016/* Get TTY auditing status */
  #define AUDIT_TTY_SET 1017/* Set TTY auditing status */
 +#define AUDIT_CREATE_NS   1018/* Create new audit namespace */
  
  #define AUDIT_FIRST_USER_MSG  1100/* Userspace messages mostly 
 uninteresting to kernel */
  #define AUDIT_USER_AVC1107/* We filter this differently */
 diff --git a/kernel/audit.c b/kernel/audit.c
 index c4d4291..86212d3 100644
 --- a/kernel/audit.c
 +++ b/kernel/audit.c
 @@ -596,6 +596,12 @@ static int audit_netlink_ok(struct sk_buff *skb, u16 
 msg_type)
!capable(CAP_AUDIT_CONTROL))
err = -EPERM;
break;
 +  case AUDIT_CREATE_NS:
 +  /* Allow privileged user in user namespace to
 +   * create audit namespace */
 +  if (!ns_capable(current_user_ns(), CAP_AUDIT_CONTROL))
 +  err = -EPERM;
 +  break;
case AUDIT_USER:
case AUDIT_FIRST_USER_MSG ... AUDIT_LAST_USER_MSG:
case AUDIT_FIRST_USER_MSG2 ... AUDIT_LAST_USER_MSG2:
 @@ -735,6 +741,22 @@ static int audit_receive_msg(struct sk_buff *skb, 
 struct nlmsghdr *nlh)
if (status_get->mask & AUDIT_STATUS_BACKLOG_LIMIT)
err = 
 audit_set_backlog_limit(status_get->backlog_limit);
break;
 +  case AUDIT_CREATE_NS:
 +  err = unshare_audit_namespace();
 +
 +  if (audit_enabled == AUDIT_OFF)
 +  break;
 +
 +  ab = audit_log_start_ns(ns, NULL, GFP_KERNEL, AUDIT_CREATE_NS);
 +  if (ab) {
 +  audit_log_format(ab, "Create audit namespace");
 +  audit_log_session_info(ab);
 +  audit_log_task_context(ab);
 +  audit_log_format(ab, "res=%d", err ? 0 : 1);
 +  audit_log_end_ns(ns, ab);
 +  }
 +
 +  break;
case AUDIT_USER:
case AUDIT_FIRST_USER_MSG ... AUDIT_LAST_USER_MSG:
case AUDIT_FIRST_USER_MSG2 ... AUDIT_LAST_USER_MSG2:
 diff --git a/kernel/audit_namespace.c b/kernel/audit_namespace.c
 index 6d9cb8f..28c608e 100644
 --- a/kernel/audit_namespace.c
 +++ b/kernel/audit_namespace.c
 @@ -6,3 +6,32 @@ struct audit_namespace init_audit_ns = {
.user_ns = &init_user_ns,
  };
  EXPORT_SYMBOL_GP

Re: [PATCH] USB: core: Add warm reset while reset-resuming SuperSpeed HUBs

[Vikas Sajjan]

Hi Alan,

On Mon, Dec 9, 2013 at 8:54 PM, Alan Stern  wrote:
> On Mon, 9 Dec 2013, Vikas Sajjan wrote:
>
>> Does warm reset while activating SuperSpeed HUBs if the hub activate type
>> is HUB_RESET_RESUME.
>>
>> When we do Suspend-to-RAM with (any one of the 16, 32, 64 Jetflash) transcend
>> USB 3.0 device connected on 3.0 port, during resume I noticed that the
>> XHCI controller has moved to sometimes RECOVERY, POLLING or INACTIVE STATE.
>> This behaviour is inconsistent and the connection with connected USB 3.0 
>> device
>> on 3.0 port was LOST.
>>
>> Doing warm reset while activating SuperSpeed HUBs if the hub
>> activate type is HUB_RESET_RESUME, gets the connected device to the stable 
>> state.
>>
>> Reviewed at https://chromium-review.googlesource.com/#/c/177132/
>>
>> Tested on exynos5420 and exynos5250 with Transcend Jetflash USB 3.0 device 
>> (8564:1000)
>>
>> rebased on Greg Kroah-Hartman's usb-next
>> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
>>
>> Signed-off-by: Vikas Sajjan 
>> ---
>>  drivers/usb/core/hub.c |   41 +
>>  1 file changed, 25 insertions(+), 16 deletions(-)
>>
>> diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
>> index a7c04e2..d8432b0 100644
>> --- a/drivers/usb/core/hub.c
>> +++ b/drivers/usb/core/hub.c
>
>> @@ -1093,6 +1108,16 @@ static void hub_activate(struct usb_hub *hub, enum 
>> hub_activation_type type)
>>   u16 portstatus, portchange;
>>
>>   portstatus = portchange = 0;
>> +
>> + /* Some connected devices might be still in unknown state even
>> +  * after reset-resume, a WARM_RESET gets the connected device
>> +  * to the normal state.
>> +  */
>> + if (udev && hub_is_superspeed(hub->hdev) &&
>> + type == HUB_RESET_RESUME)
>> + hub_port_reset(hub, port1, NULL,
>> + HUB_BH_RESET_TIME, true);
>
> Please don't do this all the time to every attached port.  Do it only
> when it is really needed.
>
> Shouldn't you pass udev as the third argument?  If not, please explain
> why not.

yea, I have NOT tried passing udev as the third argument.


>
> Finally, I don't see why you put this in hub_activate().  Isn't it more
> closely connected with the reset-resume procedure for the child device?


I was trying to add a FIX in usb_port_resume(), but in our case we
have CONFIG_USB_DEFAULT_PERSIST disabled.

Interestingly, if I disable the CONFIG_USB_DEFAULT_PERSIST, then the
function usb_port_resume() will never be called and transcend Jetflash
device Suspend-to-RAM fails.

In normal scenario (ie., CONFIG_USB_DEFAULT_PERSIST=y) the sequence is:
===
Step 1: For Root HUB :
usb_resume_both() ---> usb_resume_device() -> generic_resume() -->
hcd_bus_resume() --> xhci_bus_resume().
  |
  |-->usb_resume_interface() --->
hub_reset_resume() -->  xhci_update_hub_device()

Step 2:  For the Device connected
usb_resume_both() ---> usb_resume_device() ->
generic_resume()-->usb_port_resume()-->hub_port_logical_disconnect()
--> hub_port_disable() --> hub_usb3_port_disable().


In our scenario (ie., CONFIG_USB_DEFAULT_PERSIST=N) the sequence is:
===
Step 1: For Root HUB
usb_resume_both() ---> usb_resume_device() -> generic_resume() -->
hcd_bus_resume() --> xhci_bus_resume().
  |
  |-->usb_resume_interface() --->
hub_reset_resume() -->  xhci_update_hub_device()

Step 2 :  Never occurs

So Suspend-to-RAM fails.

Hence i added a FIX in  hub_reset_resume().

Let me know if I am wrong.

>
> Alan Stern
>
> --
> 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: [PATCH] Staging: android: fix parantheses coding style issue in alarm-dev.c

[Preetam D'Souza]

On Mon, Dec 9, 2013 at 8:04 PM, Greg KH  wrote:
>
> linux-next or the subsystem-specific tree (for drivers/staging/ that
> would be the staging.git tree at git.kernel.org, and use the
> staging-next branch.)
>
> hope this helps,
>
> greg k-h

Got it! Thanks for the heads UP, will switch over to *-next.

-Preetam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 01/14] tools lib traceevent: Get rid of malloc_or_die() in show_error()

[Namhyung Kim]

On Tue, 10 Dec 2013 14:01:44 +0900, Namhyung Kim wrote:
> On Mon, 9 Dec 2013 21:14:10 -0500, Steven Rostedt wrote:
>> On Tue, 10 Dec 2013 11:03:44 +0900
>> Namhyung Kim  wrote:
>>
>>> What about returning error code rather than string?  This way we won't
>>> worry about the allocation of the error string itself.
>>> 
>>> But the downside of it is loosing a positional info of the error.
>>> Hmm.. what about using a static buffer in pevent for it then?
>>
>> A static buffer may be the solution. Never need to worry about
>> allocating it on error, as it will already be allocated. And we can add
>> APIs to print it nicely.
>>
>> Perhaps call it
>>
>>  pevent->filter_error_buffer
>>
>> ?

Hmm.. thinking about it twice, if it's only for filter functions
wouldn't it be better moving it to event_filter rather than pevent?

filter->error_buffer

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/

Re: [PATCH v5 tip/core/locking 6/7] locking: Add an smp_mb__after_unlock_lock() for UNLOCK+LOCK barrier

[Paul E. McKenney]

On Mon, Dec 09, 2013 at 05:34:17PM -0800, Josh Triplett wrote:
> On Mon, Dec 09, 2013 at 05:28:02PM -0800, Paul E. McKenney wrote:
> > From: "Paul E. McKenney" 
> > 
> > The Linux kernel has traditionally required that an UNLOCK+LOCK pair
> > act as a full memory barrier when either (1) that UNLOCK+LOCK pair
> > was executed by the same CPU or task, or (2) the same lock variable
> > was used for the UNLOCK and LOCK.  It now seems likely that very few
> > places in the kernel rely on this full-memory-barrier semantic, and
> > with the advent of queued locks, providing this semantic either requires
> > complex reasoning, or for some architectures, added overhead.
> > 
> > This commit therefore adds a smp_mb__after_unlock_lock(), which may be
> > placed after a LOCK primitive to restore the full-memory-barrier semantic.
> > All definitions are currently no-ops, but will be upgraded for some
> > architectures when queued locks arrive.
> > 
> > Signed-off-by: Paul E. McKenney 
> > Cc: Linux-Arch 
> > Cc: Ingo Molnar 
> > Cc: Peter Zijlstra 
> > Cc: Oleg Nesterov 
> > Cc: Linus Torvalds 
> 
> It seems quite unfortunate that this isn't in some common location, and
> then only overridden by architectures that need to do so.

I was thinking that include/asm-generic/barrier.h was the place, but
it is all-or-nothing, used by UP architectures, from what I can see.
I figured that if there is such a common location, posting this patch
might flush it out.  I am not sure that this single definition is worth
the creation of a common place -- or even this definition combined with
smp_read_barrier_depends().

> More importantly: you document this earlier in the patch series than you
> introduce it.

Fair point, I reversed the order of those two patches.

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] usb-storage: scsiglue: Changing the command result

[Vishal Annapurve]

Hi Greg,

Does this look fine? I will send over other patches
once you confirm.

Patch set 1:
-
[PATCH 1/3] usb: storage: Proper cmd result assignment

This change replaces DID_ABORT with DID_TIMEOUT as a command result
whenever US_FLIDX_TIMED_OUT bit is set.

This change is made to bring USB storage inline with a recent change:

commit18a4d0a22ed6c54b67af7718c305cd010f09ddf8

[SCSI] Handle disk devices which can not process medium access commands
We have experienced several devices which fail in a fashion we do not
currently handle gracefully in SCSI. After a failure these devices will
respond to the SCSI primary command set (INQUIRY, TEST UNIT READY, etc.)
but any command accessing the storage medium will time out.

As the USB storage was setting command result as aborted rather than
timed out, SCSI layer was not recognizing the above mentioned failure
pattern.

Signed-off-by: Vishal Annapurve 
---
 drivers/usb/storage/cypress_atacb.c |  1 +
 drivers/usb/storage/isd200.c|  2 +-
 drivers/usb/storage/transport.c |  8 
 drivers/usb/storage/usb.c   | 10 ++
 4 files changed, 12 insertions(+), 9 deletions(-)
---
diff --git a/drivers/usb/storage/cypress_atacb.c 
b/drivers/usb/storage/cypress_atacb.c

index 8514a2d..3477ca19 100644
--- a/drivers/usb/storage/cypress_atacb.c
+++ b/drivers/usb/storage/cypress_atacb.c
@@ -168,6 +168,7 @@ static void cypress_atacb_passthrough(struct 
scsi_cmnd *srb, struct us_data *us)

  */
 if ((srb->result != (DID_ERROR << 16) &&
 srb->result != (DID_ABORT << 16)) &&
+srb->result != (DID_TIME_OUT << 16) &&
 save_cmnd[2] & 0x20) {
 struct scsi_eh_save ses;
 unsigned char regs[8];
diff --git a/drivers/usb/storage/isd200.c b/drivers/usb/storage/isd200.c
index 599d8bf..ffd5d58 100644
--- a/drivers/usb/storage/isd200.c
+++ b/drivers/usb/storage/isd200.c
@@ -703,7 +703,7 @@ static void isd200_invoke_transport( struct us_data *us,
 /* abort processing: the bulk-only transport requires a reset
  * following an abort */
 Handle_Abort:
-srb->result = DID_ABORT << 16;
+srb->result = DID_TIME_OUT << 16;

 /* permit the reset transfer to take place */
 clear_bit(US_FLIDX_ABORTING, &us->dflags);
diff --git a/drivers/usb/storage/transport.c 
b/drivers/usb/storage/transport.c

index 22c7d43..6a90161 100644
--- a/drivers/usb/storage/transport.c
+++ b/drivers/usb/storage/transport.c
@@ -607,8 +607,8 @@ void usb_stor_invoke_transport(struct scsi_cmnd 
*srb, struct us_data *us)

  * short-circuit all other processing
  */
 if (test_bit(US_FLIDX_TIMED_OUT, &us->dflags)) {
-usb_stor_dbg(us, "-- command was aborted\n");
-srb->result = DID_ABORT << 16;
+usb_stor_dbg("-- command was aborted because of timeout\n");
+srb->result = DID_TIME_OUT << 16;
 goto Handle_Errors;
 }

@@ -717,8 +717,8 @@ Retry_Sense:
 scsi_eh_restore_cmnd(srb, &ses);

 if (test_bit(US_FLIDX_TIMED_OUT, &us->dflags)) {
-usb_stor_dbg(us, "-- auto-sense aborted\n");
-srb->result = DID_ABORT << 16;
+usb_stor_dbg("-- auto-sense aborted due to timeout\n");
+srb->result = DID_TIME_OUT << 16;

 /* If SANE_SENSE caused this problem, disable it */
 if (sense_size != US_SENSE_SIZE) {
diff --git a/drivers/usb/storage/usb.c b/drivers/usb/storage/usb.c
index 5c4fe07..04a68eb 100644
--- a/drivers/usb/storage/usb.c
+++ b/drivers/usb/storage/usb.c
@@ -325,7 +325,7 @@ static int usb_stor_control_thread(void * __us)

 /* has the command timed out *already* ? */
 if (test_bit(US_FLIDX_TIMED_OUT, &us->dflags)) {
-us->srb->result = DID_ABORT << 16;
+us->srb->result = DID_TIME_OUT << 16;
 goto SkipForAbort;
 }

@@ -379,7 +379,8 @@ static int usb_stor_control_thread(void * __us)
 scsi_lock(host);

 /* indicate that the command is done */
-if (us->srb->result != DID_ABORT << 16) {
+if ((us->srb->result != DID_ABORT << 16) &&
+(us->srb->result != DID_TIME_OUT << 16)) {
 usb_stor_dbg(us, "scsi cmd done, result=0x%x\n",
  us->srb->result);
 us->srb->scsi_done(us->srb);
@@ -390,8 +391,9 @@ SkipForAbort:

 /* If an abort request was received we need to signal that
  * the abort has finished.  The proper test for this is
- * the TIMED_OUT flag, not srb->result == DID_ABORT, because
- * the timeout might have occurred after the command had
+ * the TIMED_OUT flag, not srb->result == DID_ABORT or
+ * srb->result == DID_TIMEOUT , because the timeout might
+ * have occurred after the command had
  * already completed with a different result code. */
 if (test_bit(US_FLIDX_TIMED_OUT, &us->dflags)) {
 complete(&(us->notify));
---

Regards,
Vishal

On Monday 09 

Re: [PATCH] USB: core: Add warm reset while reset-resuming SuperSpeed HUBs

[Vikas Sajjan]

Hi Sarah,

On Mon, Dec 9, 2013 at 11:54 PM, Sarah Sharp
 wrote:
> On Mon, Dec 09, 2013 at 10:24:52AM -0500, Alan Stern wrote:
>> On Mon, 9 Dec 2013, Vikas Sajjan wrote:
>>
>> > Does warm reset while activating SuperSpeed HUBs if the hub activate type
>> > is HUB_RESET_RESUME.
>> >
>> > When we do Suspend-to-RAM with (any one of the 16, 32, 64 Jetflash) 
>> > transcend
>> > USB 3.0 device connected on 3.0 port, during resume I noticed that the
>> > XHCI controller has moved to sometimes RECOVERY, POLLING or INACTIVE STATE.
>> > This behaviour is inconsistent and the connection with connected USB 3.0 
>> > device
>> > on 3.0 port was LOST.
>
> Does the device eventually re-connect on the USB port?  Or is warm reset
> necessary to make the device connect?

Yes, warm reset was necesssary, without which the device was NOT reconnecting.

>
> Does the xHCI register restore complete after resume from S3, or is
> power lost?  I'm trying to figure out whether xhci_reset is called
> before your issue is triggered.


The reason why I came up with this solution is during xhci_resume(),
it enters below condition and marks the reset_resume flag for the
ROOT_HUB as 1

/* If restore operation fails, re-initialize the HC during resume */
if ((temp & STS_SRE) || hibernated) {
/* Let the USB core know _both_ roothubs lost power. */
 usb_root_hub_lost_power(xhci->main_hcd->self.root_hub);
 usb_root_hub_lost_power(xhci->shared_hcd->self.root_hub);


>
>> > Doing warm reset while activating SuperSpeed HUBs if the hub
>> > activate type is HUB_RESET_RESUME, gets the connected device to the stable 
>> > state.
>> >
>> > Reviewed at https://chromium-review.googlesource.com/#/c/177132/
>> >
>> > Tested on exynos5420 and exynos5250 with Transcend Jetflash USB 3.0 device 
>> > (8564:1000)
>
> Is this issue specific to the particular USB device manufacturer
> (Transcend)?  Does the same device lose connection on resume from S3
> with other host controller vendors?  Have you seen this issue when the
> USB 3.0 device is behind a USB 3.0 hub?


This issue was specific to this paritcular make of Transcend.

we saw this on our chromebook. I did try Suspend-to-RAM with the same
device on Intel machine running Ubuntu.
It had worked fine without any issue.

Interestingly, if I connect with analyser, Suspend-to-RAM works fine
and USB re-enumerates successfully.
so connecting Suspend-to-RAM for debugging was not helping, as it works fine.
I did put prints in multiple places to get port status, and i see that
port is in sometimes RECOVERY, POLLING or In active STATE.
The behaviour was inconsistent.


>
> I ask because this sounds like a low-level link training issue that's
> specific to the exynos host or USB device.  I would rather track down
> which hardware is to blame than generically add a warm reset for all USB
> 3.0 devices.
>
>> > rebased on Greg Kroah-Hartman's usb-next
>> > git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git
>> >
>> > Signed-off-by: Vikas Sajjan 
>> > ---
>> >  drivers/usb/core/hub.c |   41 +
>> >  1 file changed, 25 insertions(+), 16 deletions(-)
>> >
>> > diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
>> > index a7c04e2..d8432b0 100644
>> > --- a/drivers/usb/core/hub.c
>> > +++ b/drivers/usb/core/hub.c
>>
>> > @@ -1093,6 +1108,16 @@ static void hub_activate(struct usb_hub *hub, enum 
>> > hub_activation_type type)
>> > u16 portstatus, portchange;
>> >
>> > portstatus = portchange = 0;
>> > +
>> > +   /* Some connected devices might be still in unknown state even
>> > +* after reset-resume, a WARM_RESET gets the connected device
>> > +* to the normal state.
>> > +*/
>> > +   if (udev && hub_is_superspeed(hub->hdev) &&
>> > +   type == HUB_RESET_RESUME)
>> > +   hub_port_reset(hub, port1, NULL,
>> > +   HUB_BH_RESET_TIME, true);
>>
>> Please don't do this all the time to every attached port.  Do it only
>> when it is really needed.
>
> Agreed.  Can we at least limit the warm reset to devices directly
> attached to roothubs?  You can also change this code to get the port
> status and only do the warm reset if the port link state is
> USB_SS_PORT_LS_POLLING, USB_SS_PORT_LS_RX_DETECT, or
> USB_SS_PORT_LS_SS_INACTIVE.
>
>> Shouldn't you pass udev as the third argument?  If not, please explain
>> why not.
>>
>> Finally, I don't see why you put this in hub_activate().  Isn't it more
>> closely connected with the reset-resume procedure for the child device?
>
> Sarah Sharp
> --
> 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 

Re: [PATCH v5 tip/core/locking 5/7] Documentation/memory-barriers.txt: Downgrade UNLOCK+LOCK

[Paul E. McKenney]

On Mon, Dec 09, 2013 at 05:32:31PM -0800, Josh Triplett wrote:
> On Mon, Dec 09, 2013 at 05:28:01PM -0800, Paul E. McKenney wrote:
> > From: "Paul E. McKenney" 
> > 
> > Historically, an UNLOCK+LOCK pair executed by one CPU, by one task,
> > or on a given lock variable has implied a full memory barrier.  In a
> > recent LKML thread, the wisdom of this historical approach was called
> > into question: http://www.spinics.net/lists/linux-mm/msg65653.html,
> > in part due to the memory-order complexities of low-handoff-overhead
> > queued locks on x86 systems.
> > 
> > This patch therefore removes this guarantee from the documentation, and
> > further documents how to restore it via a new smp_mb__after_unlock_lock()
> > primitive.
> > 
> > Signed-off-by: Paul E. McKenney 
> > Cc: Ingo Molnar 
> > Cc: Peter Zijlstra 
> > Cc: Oleg Nesterov 
> > Cc: Linus Torvalds 
> > Cc: Will Deacon 
> > Cc: Tim Chen 
> > Cc: Andrew Morton 
> > Cc: Thomas Gleixner 
> > Cc: Waiman Long 
> > Cc: Andrea Arcangeli 
> > Cc: Andi Kleen 
> > Cc: Michel Lespinasse 
> > Cc: Davidlohr Bueso 
> > Cc: Rik van Riel 
> > Cc: Peter Hurley 
> > Cc: "H. Peter Anvin" 
> > Cc: Arnd Bergmann 
> > Cc: Benjamin Herrenschmidt 
> > ---
> >  Documentation/memory-barriers.txt | 51 
> > +--
> >  1 file changed, 44 insertions(+), 7 deletions(-)
> > 
> > diff --git a/Documentation/memory-barriers.txt 
> > b/Documentation/memory-barriers.txt
> > index a0763db314ff..efb791d33e5a 100644
> > --- a/Documentation/memory-barriers.txt
> > +++ b/Documentation/memory-barriers.txt
> > @@ -1626,7 +1626,10 @@ for each construct.  These operations all imply 
> > certain barriers:
> >   operation has completed.
> >  
> >   Memory operations issued before the LOCK may be completed after the 
> > LOCK
> > - operation has completed.
> > + operation has completed.  An smp_mb__before_spinlock(), combined
> > + with a following LOCK, acts as an smp_wmb().  Note the "w",
> > + this is smp_wmb(), not smp_mb().  The smp_mb__before_spinlock()
> > + primitive is free on many architectures.
> 
> Gah.  That seems highly error-prone; why isn't that
> "smp_wmb__before_spinlock()"?

I must confess that I wondered that myself.  I didn't create it, I am
just documenting it.

Might be worth a change, though.

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: 50 Watt idle power regression bisected to Linux-3.10

[Mike Galbraith]

Hi Len,

I'm unable to reproduce those DL980 results.  I updated the kernel and
config yesterday, and happened to run turbostat again.. and the box was
nowhere near as quiet.  I ended up spending all day futzing with the
darn thing, checking various config/kernel combos, and none produced the
previous result.

ATM, running the same exact updated kernel as the x3550 is running
(still happily) with only a couple needed drivers added:

vogelweide:~/:[130]# turbostat -P -i 60
pk cor CPU%c0  GHz  TSC SMI%c1%c3%c6 CTMP   %pc3   %pc6
 0.02 2.12 2.26   0  43.40  56.57   0.00   53  33.81   0.00
 0   0   0   0.23 2.10 2.26   5  65.47  34.30   0.00   52  10.69   0.00
 1   0   8   0.04 2.02 2.26   5  63.10  36.86   0.00   41  13.31   0.00
 2   0  16   0.04 1.90 2.26   5  35.70  64.25   0.00   43  37.88   0.00
 3   0  24   0.03 2.08 2.26   5  39.78  60.19   0.00   42  29.00   0.00
 4   0  32   0.03 1.95 2.26   5  14.64  85.33   0.00   37  65.00   0.00
 5   0  40   0.03 1.95 2.26   5  15.96  84.02   0.00   36  74.34   0.00
 6   0  48   0.02 1.99 2.26   5  36.97  63.01   0.00   37  40.20   0.00
 7   0  56   0.02 2.08 2.26   5  57.54  42.44   0.00   44   0.08   0.00
pk cor CPU%c0  GHz  TSC SMI%c1%c3%c6 CTMP   %pc3   %pc6
 0.03 2.08 2.26   0  31.24  68.73   0.00   53  44.26   0.00
 0   0   0   0.25 1.76 2.26   8  52.96  46.78   0.00   51  31.99   0.00
 1   0   8   0.03 1.96 2.26   8  50.69  49.28   0.00   41  30.80   0.00
 2   0  16   0.04 1.91 2.26   8  36.10  63.85   0.00   42  44.37   0.00
 3   0  24   0.03 1.96 2.26   8  24.15  75.82   0.00   42  59.14   0.00
 4   0  32   0.03 1.94 2.26   8  14.68  85.29   0.00   37  71.64   0.00
 5   0  40   0.03 1.94 2.26   8  16.01  83.96   0.00   36  78.62   0.00
 6   0  48   0.02 2.18 2.26   8  46.79  53.18   0.00   36  11.05   0.00
 7   0  56   0.02 2.01 2.26   8  50.84  49.14   0.00   45  26.50   0.00
pk cor CPU%c0  GHz  TSC SMI%c1%c3%c6 CTMP   %pc3   %pc6
 0.03 2.10 2.26   0  30.88  69.09   0.00   51  48.09   0.00
 0   0   0   0.23 1.84 2.26   8  51.98  47.79   0.00   50  31.06   0.00
 1   0   8   0.04 2.05 2.26   8  59.44  40.52   0.00   41  21.86   0.00
 2   0  16   0.04 1.73 2.26   8  22.87  77.09   0.00   41  62.26   0.00
 3   0  24   0.03 1.93 2.26   8   9.83  90.14   0.00   41  77.33   0.00
 4   0  32   0.03 1.90 2.26   8   8.66  91.31   0.00   37  89.16   0.00
 5   0  40   0.03 2.05 2.26   8  27.30  72.67   0.00   35  50.62   0.00
 6   0  48   0.02 2.07 2.26   8  44.81  55.17   0.00   36  18.97   0.00
 7   0  56   0.02 2.00 2.26   8  48.06  51.91   0.00   42  33.44   0.00

That, vs solid >99% pc3 for old 3.0 enterprise kernel.  What happened,
dunno, kernel called itself master.  Whatever, I don't like test bogons,
and this is one, so I thought I should let you know.  DL980 refuses to
come close to the previous result.

'nuff of that, off to the slave pits before yet another day evaporates.

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

[RFC][PATCH 1/3] timekeeping: Fix lost updates to tai adjustment

[John Stultz]

Since 48cdc135d4840 (Implement a shadow timekeeper), we have to
call timekeeping_update() after any adjustment to the timekeeping
structure in order to make sure that any adjustments to the structure
persist.

Unfortunately, the updates to the tai offset via adjtimex do not
trigger this update, causing adjustments to the tai offset to be
made and then over-written by the previous value at the next
update_wall_time() call.

This patch resovles the issue by calling timekeeping_update()
right after setting the tai offset.

Cc: Thomas Gleixner 
Cc: Prarit Bhargava 
Cc: Richard Cochran 
Cc: Ingo Molnar 
Cc: stable  #3.10+
Signed-off-by: John Stultz 
---
 kernel/time/timekeeping.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 87b4f00..6bad3d9 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -610,6 +610,7 @@ void timekeeping_set_tai_offset(s32 tai_offset)
raw_spin_lock_irqsave(&timekeeper_lock, flags);
write_seqcount_begin(&timekeeper_seq);
__timekeeping_set_tai_offset(tk, tai_offset);
+   timekeeping_update(tk, TK_MIRROR | TK_CLOCK_WAS_SET);
write_seqcount_end(&timekeeper_seq);
raw_spin_unlock_irqrestore(&timekeeper_lock, flags);
clock_was_set();
@@ -1698,7 +1699,7 @@ int do_adjtimex(struct timex *txc)
 
if (tai != orig_tai) {
__timekeeping_set_tai_offset(tk, tai);
-   update_pvclock_gtod(tk, true);
+   timekeeping_update(tk, TK_MIRROR | TK_CLOCK_WAS_SET);
clock_was_set_delayed();
}
write_seqcount_end(&timekeeper_seq);
-- 
1.8.3.2

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

[RFC][PATCH 3/3] timekeeping: Fix potential lost pv notification of time change

[John Stultz]

In 780427f0e11 (Indicate that clock was set in the pvclock
gtod notifier), logic was added to pass a CLOCK_WAS_SET
notification to the pvclock notifier chain.

While that patch added a action flag returned from
accumulate_nsecs_to_secs(), it only uses the returned value
in one location, and not in the logarithmic accumulation.

This means if a leap second triggered during the logarithmic
accumulation (which is most likely where it would happen),
the notification that the clock was set would not make it to
the pv notifiers.

This patch extends the logarithmic_accumulation pass down
that action flag so proper notification will occur.

Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: David Vrabel 
Cc: Konrad Rzeszutek Wilk 
Cc: Prarit Bhargava 
Cc: Richard Cochran 
Cc: 
Cc: stable  #3.11+
Signed-off-by: John Stultz 
---
 kernel/time/timekeeping.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index c615e9d..e429229 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -1297,7 +1297,7 @@ static inline unsigned int 
accumulate_nsecs_to_secs(struct timekeeper *tk)
  * Returns the unconsumed cycles.
  */
 static cycle_t logarithmic_accumulation(struct timekeeper *tk, cycle_t offset,
-   u32 shift)
+   u32 shift, int *action)
 {
cycle_t interval = tk->cycle_interval << shift;
u64 raw_nsecs;
@@ -1311,7 +1311,7 @@ static cycle_t logarithmic_accumulation(struct timekeeper 
*tk, cycle_t offset,
tk->cycle_last += interval;
 
tk->xtime_nsec += tk->xtime_interval << shift;
-   accumulate_nsecs_to_secs(tk);
+   *action |= accumulate_nsecs_to_secs(tk);
 
/* Accumulate raw time */
raw_nsecs = (u64)tk->raw_interval << shift;
@@ -1369,7 +1369,7 @@ static void update_wall_time(void)
struct timekeeper *tk = &shadow_timekeeper;
cycle_t offset;
int shift = 0, maxshift;
-   unsigned int action;
+   unsigned int action = 0;
unsigned long flags;
 
raw_spin_lock_irqsave(&timekeeper_lock, flags);
@@ -1404,7 +1404,7 @@ static void update_wall_time(void)
maxshift = (64 - (ilog2(ntp_tick_length())+1)) - 1;
shift = min(shift, maxshift);
while (offset >= tk->cycle_interval) {
-   offset = logarithmic_accumulation(tk, offset, shift);
+   offset = logarithmic_accumulation(tk, offset, shift, &action);
if (offset < tk->cycle_interval

[RFC][PATCH 2/3] timekeeping: Fix missing timekeeping_update in suspend path

[John Stultz]

Since 48cdc135d4840 (Implement a shadow timekeeper), we have to
call timekeeping_update() after any adjustment to the timekeeping
structure in order to make sure that any adjustments to the structure
persist.

In the timekeeping suspend path, we udpate the timekeeper
structure, so we should be sure to update the shadow-timekeeper
before releasing the timekeeping locks. Currently this isn't done.

In most cases, the next time related code to run would be
timekeeping_resume, which does update the shadow-timekeeper, but
in an abundence of caution, this patch adds the call to
timekeeping_update() in the suspend path.

Cc: Thomas Gleixner 
Cc: Prarit Bhargava 
Cc: Richard Cochran 
Cc: Ingo Molnar 
Cc: stable  #3.10+
Signed-off-by: John Stultz 
---
 kernel/time/timekeeping.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 6bad3d9..c615e9d 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -1024,6 +1024,8 @@ static int timekeeping_suspend(void)
timekeeping_suspend_time =
timespec_add(timekeeping_suspend_time, delta_delta);
}
+
+   timekeeping_update(tk, TK_MIRROR);
write_seqcount_end(&timekeeper_seq);
raw_spin_unlock_irqrestore(&timekeeper_lock, flags);
 
-- 
1.8.3.2

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

[RFC][PATCH 0/3] Couple of timekeeping fixes

[John Stultz]

I was looking into the lockdep splat reported by Sasha yesterday
and came across a few issues (unfortunately not related) in the
timekeeping code.

The first two are issues related to not updating the shadow
timekeeper after making changes to the timekeeper structure.
This  means those updates could be lost the next time we
do update_wall_time(), since update_wall_time assumes the
shadow_timekeeper is current as well.

The last change is an obvious issue that I should have
caught in review, but where we handle notifying the pvclock
code if time was set, there's one case in
logarithmic_accumulation where we just don't pass that flag
down.

Of the three patches, the first is really the most critical.
I'm thinking of pushing that one into 3.13, and immediately
back to 3.12-stable and 3.10-stable. Then leaving the last
two for 3.14, and pushing back to 3.13/10-stable once those
changes are merged.

I'm still running some tests on these, but I wanted to send
them out as RFCs to get some extra review and thoughts
before I send them out for real.

thanks
-john


Cc: Thomas Gleixner 
Cc: Prarit Bhargava 
Cc: Richard Cochran 
Cc: Ingo Molnar 
Cc: David Vrabel 

John Stultz (3):
  timekeeping: Fix lost updates to tai adjustment
  timekeeping: Fix missing timekeeping_update in suspend path
  timekeeping: Fix potential lost pv notification of time change

 kernel/time/timekeeping.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

-- 
1.8.3.2

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

Re: [patch] perf tools: perf list broken on ARM

[Namhyung Kim]

On Mon, 9 Dec 2013 22:58:46 -0500 (EST), Vince Weaver wrote:
> On Tue, 10 Dec 2013, Namhyung Kim wrote:
>
>> Hi Vince,
>> Okay, the reason I set the bit was consideration of a very strict
>> perf_event_paranoid setting (-2).
>> 
>> So maybe we can try it again with the bit cleared after a failure, or
>> checking the paranoid setting first.
>
> If perf_event_paranoid is set to 2 then you should get EPERM rather than 
> ENOENT or EINVAL, right?  Maybe that could be used too.

Ah, yes, it's 2. :)  And it also can use the return value then.

>
> As a side note, why doesn't paranoid 2 block events that don't have
> exclude_hv set?

Hmm.. maybe because it predated the bit?

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/

Re: [PATCH 01/14] tools lib traceevent: Get rid of malloc_or_die() in show_error()

[Namhyung Kim]

On Mon, 9 Dec 2013 21:14:10 -0500, Steven Rostedt wrote:
> On Tue, 10 Dec 2013 11:03:44 +0900
> Namhyung Kim  wrote:
>
>> What about returning error code rather than string?  This way we won't
>> worry about the allocation of the error string itself.
>> 
>> But the downside of it is loosing a positional info of the error.
>> Hmm.. what about using a static buffer in pevent for it then?
>
> A static buffer may be the solution. Never need to worry about
> allocating it on error, as it will already be allocated. And we can add
> APIs to print it nicely.
>
> Perhaps call it
>
>   pevent->filter_error_buffer
>
> ?

Okay, I'll go with this.

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/

Re: [PATCH v13 11/16] mm: list_lru: add per-memcg lists

[Dave Chinner]

On Mon, Dec 09, 2013 at 12:05:52PM +0400, Vladimir Davydov wrote:
> There are several FS shrinkers, including super_block::s_shrink, that
> keep reclaimable objects in the list_lru structure. That said, to turn
> them to memcg-aware shrinkers, it is enough to make list_lru per-memcg.
> 
> This patch does the trick. It adds an array of LRU lists to the list_lru
> structure, one for each kmem-active memcg, and dispatches every item
> addition or removal operation to the list corresponding to the memcg the
> item is accounted to.
> 
> Since we already pass a shrink_control object to count and walk list_lru
> functions to specify the NUMA node to scan, and the target memcg is held
> in this structure, there is no need in changing the list_lru interface.
> 
> The idea lying behind the patch as well as the initial implementation
> belong to Glauber Costa.
> 
> Signed-off-by: Vladimir Davydov 
> Cc: Glauber Costa 
> Cc: Dave Chinner 
> Cc: Johannes Weiner 
> Cc: Michal Hocko 
> Cc: Andrew Morton 
> Cc: Al Viro 
> Cc: Balbir Singh 
> Cc: KAMEZAWA Hiroyuki 
> ---
>  include/linux/list_lru.h   |   44 +++-
>  include/linux/memcontrol.h |   13 +++
>  mm/list_lru.c  |  242 
> ++--
>  mm/memcontrol.c|  158 -
>  4 files changed, 416 insertions(+), 41 deletions(-)
> 
> diff --git a/include/linux/list_lru.h b/include/linux/list_lru.h
> index 34e57af..e8add3d 100644
> --- a/include/linux/list_lru.h
> +++ b/include/linux/list_lru.h
> @@ -28,11 +28,47 @@ struct list_lru_node {
>   longnr_items;
>  } cacheline_aligned_in_smp;
>  
> +struct list_lru_one {
> + struct list_lru_node *node;
> + nodemask_t active_nodes;
> +};
> +
>  struct list_lru {
> - struct list_lru_node*node;
> - nodemask_t  active_nodes;
> + struct list_lru_one global;
> +#ifdef CONFIG_MEMCG_KMEM
> + /*
> +  * In order to provide ability of scanning objects from different
> +  * memory cgroups independently, we keep a separate LRU list for each
> +  * kmem-active memcg in this array. The array is RCU-protected and
> +  * indexed by memcg_cache_id().
> +  */
> + struct list_lru_one **memcg;

OK, as far as I can tell, this is introducing a per-node, per-memcg
LRU lists. Is that correct?

If so, then that is not what Glauber and I originally intended for
memcg LRUs. per-node LRUs are expensive in terms of memory and cross
multiplying them by the number of memcgs in a system was not a good
use of memory.

According to Glauber, most memcgs are small and typically confined
to a single node or two by external means and therefore don't need the
scalability numa aware LRUs provide. Hence the idea was that the
memcg LRUs would just be a single LRU list, just like a non-numa
aware list_lru instantiation. IOWs, this is the structure that we
had decided on as the best compromise between memory usage,
complexity and memcg awareness:

global list --- node 0 lru
node 1 lru
.
node nr_nodes lru
memcg lists memcg 0 lru
memcg 1 lru
.
memcg nr_memcgs lru

and the LRU code internally would select either a node or memcg LRU
to iterated based on the scan information coming in from the
shrinker. i.e.:


struct list_lru {
struct list_lru_node*node;
nodemask_t  active_nodes;
#ifdef MEMCG
struct list_lru_node**memcg;



>  bool list_lru_add(struct list_lru *lru, struct list_head *item)
>  {
> - int nid = page_to_nid(virt_to_page(item));
> - struct list_lru_node *nlru = &lru->node[nid];
> + struct page *page = virt_to_page(item);
> + int nid = page_to_nid(page);
> + struct list_lru_one *olru = lru_of_page(lru, page);
> + struct list_lru_node *nlru = &olru->node[nid];

Yeah, that's per-memcg, per-node dereferencing. And, FWIW, olru/nlru
are bad names - that's the convention typically used for "old "
and "new " pointers

As it is, it shouldn't be necessary - lru_of_page() should just
return a struct list_lru_node

> +int list_lru_init(struct list_lru *lru)
> +{
> + int err;
> +
> + err = list_lru_init_one(&lru->global);
> + if (err)
> + goto fail;
> +
> + err = memcg_list_lru_init(lru);
> + if (err)
> + goto fail;
> +
> + return 0;
> +fail:
> + list_lru_destroy_one(&lru->global);
> + lru->global.node = NULL; /* see list_lru_destroy() */
> + return err;
> +}

I suspect we have users of list_lru that don't want memcg bits added
to them. Hence I think we want to leave list_lru_init() alone and
add a list_lru_init_memcg() variant that makes the LRU memcg aware.
i.e. if the shrinker is not going to be memcg aware, then we don't
want the LRU to be memcg aware, either

>  EXPORT_SYMBOL_G

Re: [PATCH 2/2] i2c: exynos5: configure fifo_depth based on HSI2C module version

[Naveen Krishna Ch]

Hello Tomasz,


On 9 December 2013 22:01, Tomasz Figa  wrote:
>
> Hi Naveen,
>
> On Friday 22 of November 2013 11:44:11 Naveen Krishna Chatradhi wrote:
> > fifo_depth of the HSI2C is not constant
> > Exynos5420 and Exynos5250 supports fifo_depth of 64bytes
> > Exynos5260 supports fifo_depth of 16bytes
> >
> > This patch configures the fifo_depth based on HSI2C modules version.
> > Signed-off-by: Naveen Krishna Chatradhi 
> > ---
> >  drivers/i2c/busses/i2c-exynos5.c |   29 ++---
> >  1 file changed, 18 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-exynos5.c 
> > b/drivers/i2c/busses/i2c-exynos5.c
> > index cbb49e2..19277d8 100644
> > --- a/drivers/i2c/busses/i2c-exynos5.c
> > +++ b/drivers/i2c/busses/i2c-exynos5.c
> > @@ -77,12 +77,6 @@
> >  #define HSI2C_RXFIFO_TRIGGER_LEVEL(x)((x) << 4)
> >  #define HSI2C_TXFIFO_TRIGGER_LEVEL(x)((x) << 16)
> >
> > -/* As per user manual FIFO max depth is 64bytes */
> > -#define HSI2C_FIFO_MAX   0x40
> > -/* default trigger levels for Tx and Rx FIFOs */
> > -#define HSI2C_DEF_TXFIFO_LVL (HSI2C_FIFO_MAX - 0x30)
> > -#define HSI2C_DEF_RXFIFO_LVL (HSI2C_FIFO_MAX - 0x10)
> > -
> >  /* I2C_TRAILING_CTL Register bits */
> >  #define HSI2C_TRAILING_COUNT (0xf)
> >
> > @@ -187,6 +181,9 @@ struct exynos5_i2c {
> >
> >   /* Version of HS-I2C Hardware */
> >   unsigned intversion;
> > +
> > + /* FIFO depth */
> > + unsigned intfifo_depth;
> >  };
> >
> >  enum hsi2c_version {
> > @@ -437,7 +434,7 @@ static irqreturn_t exynos5_i2c_irq(int irqno, void 
> > *dev_id)
> >   fifo_status = readl(i2c->regs + HSI2C_FIFO_STATUS);
> >   fifo_level = HSI2C_TX_FIFO_LVL(fifo_status);
> >
> > - len = HSI2C_FIFO_MAX - fifo_level;
> > + len = i2c->fifo_depth - fifo_level;
> >   if (len > (i2c->msg->len - i2c->msg_ptr))
> >   len = i2c->msg->len - i2c->msg_ptr;
> >
> > @@ -505,6 +502,7 @@ static void exynos5_i2c_message_start(struct 
> > exynos5_i2c *i2c, int stop)
> >   u32 i2c_auto_conf = 0;
> >   u32 fifo_ctl;
> >   unsigned long flags;
> > + unsigned short trig_lvl;
> >
> >   i2c_ctl = readl(i2c->regs + HSI2C_CTL);
> >   i2c_ctl &= ~(HSI2C_TXCHON | HSI2C_RXCHON);
> > @@ -515,13 +513,19 @@ static void exynos5_i2c_message_start(struct 
> > exynos5_i2c *i2c, int stop)
> >
> >   i2c_auto_conf = HSI2C_READ_WRITE;
> >
> > - fifo_ctl |= HSI2C_RXFIFO_TRIGGER_LEVEL(HSI2C_DEF_TXFIFO_LVL);
> > + trig_lvl = (i2c->msg->len > i2c->fifo_depth) ?
> > + (i2c->fifo_depth * 3/4) : i2c->msg->len;
>
> This patch changes the fifo trigger level calculation (it's dependent now
> on message length), not just maximum fifo size, as the description says.
Actually, message->length need not be involved in this calculation.
Involving msg->len
will raise another interrupt for every small transactions. It better be avoided.
> It should be split into two separate patches, explaining why both changes
> are necessary.
I will split the fifo_depth configuration code along with comments addressed on
https://lkml.org/lkml/2013/11/22/31

I can think of 3 ways to address the h/w version changes
1. Compatible string as i implemented
2. Varient struct
3. Passing the information via device tree
How about passing fifo_depth from device tree information.

Currently, HSI2C Module on Exynso5260 is not another H/W version.
It only defer in fifo_depth and init sequence needs a reset.

>
>
> Best regards,
> Tomasz
>



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

Re: [PATCH][RESEND] clocksource: tegra: remove deprecated IRQF_DISABLED

[Michael Opdenacker]

On 12/09/2013 06:06 PM, Stephen Warren wrote:
> On 12/09/2013 02:35 AM, Michael Opdenacker wrote:
>> This patch proposes to remove the use of the IRQF_DISABLED flag
>>
>> It's a NOOP since 2.6.35 and it will be removed one day.
> I assume that the maintainers for drivers/clocksource/ will apply this.
> If not, let me know, and I can take it through the Tegra tree.
>
Yes, Daniel Lezcano told me he applied the 3 patches I sent (thanks!).

Thank you for your support!

Cheers,

Michael.

-- 
Michael Opdenacker, CEO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
+33 484 258 098

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

Re: [PATCH v7 2/5] usb: gadget: add quirk_ep_out_aligned_size field to struct usb_gadget

[Felipe Balbi]

On Mon, Dec 09, 2013 at 07:35:19PM -0800, David Cohen wrote:
> On 12/09/2013 06:34 PM, Michal Nazarewicz wrote:
> > dOn Tue, Dec 10 2013, David Cohen wrote:
> >> Due to USB controllers may have different restrictions, usb gadget layer
> >> needs to provide a generic way to inform gadget functions to complain
> >> with non-standard requirements.
> >>
> >> This patch adds 'quirk_ep_out_aligned_size' field to struct usb_gadget
> >> to inform when controller's epout requires buffer size to be aligned to
> >> MaxPacketSize. A helper is also provided to align buffer size when
> >> necessary.
> >>
> >> Signed-off-by: David Cohen 
> >> Cc: Alan Stern 
> >> Cc: Michal Nazarewicz 
> > 
> > Acked-by: Michal Nazarewicz 
> > 
> >> ---
> >>  include/linux/usb/gadget.h | 20 
> >>  1 file changed, 20 insertions(+)
> >>
> >> diff --git a/include/linux/usb/gadget.h b/include/linux/usb/gadget.h
> >> index 23b3bfd0a842..cae8a6216551 100644
> >> --- a/include/linux/usb/gadget.h
> >> +++ b/include/linux/usb/gadget.h
> >> @@ -502,6 +502,8 @@ struct usb_gadget_ops {
> >>   *only supports HNP on a different root port.
> >>   * @b_hnp_enable: OTG device feature flag, indicating that the A-Host
> >>   *enabled HNP support.
> >> + * @quirk_ep_out_aligned_size: epout requires buffer size to be aligned to
> >> + *MaxPacketSize.
> >>   *
> >>   * Gadgets have a mostly-portable "gadget driver" implementing device
> >>   * functions, handling all usb configurations and interfaces.  Gadget
> >> @@ -541,6 +543,7 @@ struct usb_gadget {
> >>unsignedb_hnp_enable:1;
> >>unsigneda_hnp_support:1;
> >>unsigneda_alt_hnp_support:1;
> >> +  unsignedquirk_ep_out_aligned_size:1;
> >>  };
> >>  #define work_to_gadget(w) (container_of((w), struct usb_gadget, work))
> >>  
> >> @@ -559,6 +562,23 @@ static inline struct usb_gadget 
> >> *dev_to_usb_gadget(struct device *dev)
> >>  
> >>  
> >>  /**
> >> + * usb_ep_align_maybe - returns @len aligned to ep's maxpacketsize if 
> >> gadget
> >> + *requires quirk_ep_out_aligned_size, otherwise reguens len.
> > 
> > “returns”
> 
> I've got no idea how returns became reguens :)
> But maybe Felipe can fix it when applying?

Sure, but you owe me a beer hehe :-)

-- 
balbi


signature.asc
Description: Digital signature