*****SPAM***** MEDIUM * Representative/collecting Agent Needed:DL

[Jinjing Honghui]

Good day to you,

It is my pleasure to forward the following offer of Appointment to you . We are 
a Chinese/Japanese based company who specializes in the production of Heavy 
duty lifting equipment, We are in search of a Reputable Company/Individual that 
can act as our Company sales representative/collecting agent in Canada and USA 
(help as a link between us and our clients in your geographical region). We 
would be obliged if you could render your services to us and get paid monthly 
with additional commission without leaving or affecting your present job.If 
interested, kindly indicate by sending an email to: upon your response to this 
letter you would be briefed on more details.

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

Re: [Intel-gfx] [regression] [git pull] drm for 4.3

[Dave Airlie]

On 20 October 2015 at 07:54, Daniel Vetter  wrote:
> On Mon, Oct 19, 2015 at 04:19:08PM -0400, da...@codemonkey.org.uk wrote:
>> On Wed, Sep 30, 2015 at 08:56:26AM +0200, Daniel Vetter wrote:
>>
>>  > > The warning on boot seems to be gone as of rc3, but I can now trigger 
>> this pretty easily..
>>  >
>>  > http://patchwork.freedesktop.org/patch/60618/
>>
>> Back from several weeks of travel..  I tried again with rc6, and
>> I'm still seeing the same traces.
>
> Oh crap, applied patch to wrong tree. We need to cherry-pick
>
> commit 621bd0f6982badd6483acb191eb7b6226a578328
> Author: Daniel Vetter 
> Date:   Tue Sep 29 09:56:53 2015 +0200
>
> drm: Fix locking for sysfs dpms file
>
> to drm-fixes. Sorry about that screw-up. Dave, can you pls do that one? It
> even comes with the needed cc: stable included (since the locking breakage
> was done in 4.0, it only surface due to a new warning in 4.3).

That is already in Linus's tree, I picked it last week I think.

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

linux-next: Tree for Oct 20

[Stephen Rothwell]

Hi all,

Changes since 20151019:

My "during the merges" builds are now PowerPC hosted which only really
affects the perf build since it is done natively.

I used the new h8300 tree even though it is not ideal.

The battery tree still had its build failure so I used the version from
next-20150925.

The tip tree gained a conflict against the dt-rh tree.

Non-merge commits (relative to Linus' tree): 8510
 6747 files changed, 321671 insertions(+), 149432 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig for x86_64,
a multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), it is also built with powerpc allnoconfig
(32 and 64 bit), ppc44x_defconfig, allyesconfig (this fails its final
link) and pseries_le_defconfig and i386, sparc, sparc64 and arm defconfig.

Below is a summary of the state of the merge.

I am currently merging 228 trees (counting Linus' and 34 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

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

$ git checkout master
$ git reset --hard stable
Merging origin/master (1099f8604411 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging fixes/master (25cb62b76430 Linux 4.3-rc5)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (049e6dde7e57 Linux 4.3-rc4)
Merging arm-current/fixes (868e87ccda24 ARM: make RiscPC depend on MMU)
Merging m68k-current/for-linus (95bc06ef049b m68k/defconfig: Update defconfigs 
for v4.3-rc1)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5)
Merging powerpc-fixes/fixes (abb39bc792aa selftests/powerpc: Fix build failure 
of load_unaligned_zeropad test)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (73958c651fbf sparc64: use ENTRY/ENDPROC in VISsave)
Merging net/master (37850e37fcfb net: bcmgenet: Fix early link interrupt 
enabling)
Merging ipsec/master (4e077237cfb6 xfrm: Fix state threshold configuration from 
userspace)
Merging ipvs/master (6ece90f9a13e netfilter: fix Kconfig dependencies for 
nf_dup_ipv{4,6})
Merging sound-current/for-linus (e8d65a8d9852 ALSA: hda - Fix inverted internal 
mic on Lenovo G50-80)
Merging pci-current/for-linus (1266963170f5 PCI: Prevent out of bounds access 
in numa_node override)
Merging wireless-drivers/master (de28a05ee28e Merge tag 
'iwlwifi-for-kalle-2015-10-05' of 
git://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging driver-core.current/driver-core-linus (9ffecb102835 Linux 4.3-rc3)
Merging tty.current/tty-linus (f235f664a8af fbcon: initialize blink interval 
before calling fb_set_par)
Merging usb.current/usb-linus (fd7cd061adcf xhci: Add spurious wakeup quirk for 
LynxPoint-LP controllers)
Merging usb-gadget-fixes/fixes (25cb62b76430 Linux 4.3-rc5)
Merging usb-serial-fixes/usb-linus (049e6dde7e57 Linux 4.3-rc4)
Merging staging.current/staging-linus (4301de3b0ac4 Merge tag 
'iio-fixes-for-4.3a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio 
into staging-linus)
Merging char-misc.current/char-misc-linus (25cb62b76430 Linux 4.3-rc5)
Merging input-current/for-linus (c8a1978e07c4 Input: sur40 - add dependency on 
VIDEO_V4L2)
Merging crypto-current/master (8996eafdcbad crypto: ahash - ensure statesize is 
non-zero)
Merging ide/master (d681f1166919 ide: remove deprecated use of pci api)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (275d7d44d802 module: Fix locking in symbol_put_addr())
Merging vfio-fixes/for-linus (4bc94d5dc95d vfio: Fix lockdep issue)
Merging kselftest-fixes/fixes (ae7858180510 selftests: exec: revert to default 
emit rule)
Merging backlight-fixes/for-backlight-fixe

linux-next: build warning after merge of the powerpc tree

[Stephen Rothwell]

Hi all,

After merging the powerpc tree, today's linux-next build (powerpc
allyesconfig) produced this warning:

WARNING: vmlinux.o(.text+0x9367c): Section mismatch in reference from the 
function .msi_bitmap_alloc() to the function 
.init.text:.memblock_virt_alloc_try_nid()
The function .msi_bitmap_alloc() references
the function __init .memblock_virt_alloc_try_nid().
This is often because .msi_bitmap_alloc lacks a __init
annotation or the annotation of .memblock_virt_alloc_try_nid is wrong.

Introduced (probably) by commit

  cb2d3883c603 ("powerpc/msi: Free the bitmap if it was slab allocated")

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

Re: [PATCH 1/2] NFC: delete null dereference

[Samuel Ortiz]

Hi Julia,

On Sat, Oct 17, 2015 at 11:32:19AM +0200, Julia Lawall wrote:
> The exit label performs device_unlock(>dev);, which will fail when dev
> is NULL, and nfc_put_device(dev);, which is not useful when dev is NULL, so
> just exit the function immediately.
> 
> Problem found using scripts/coccinelle/null/deref_null.cocci
> 
> Signed-off-by: Julia Lawall 
> 
> ---
>  net/nfc/netlink.c |6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
Applied to nfc-next, thanks.

Cheers,
Samuel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] NFC: nfcwilink: Drop a useless static qualifier

[Samuel Ortiz]

Hi Christophe,

On Tue, Oct 13, 2015 at 08:31:04AM +0200, Christophe JAILLET wrote:
> There is no need to have the 'struct nfcwilink *drv' variable static in the
> probe function.
> It only wastes a few bytes of memory.
> 
> Signed-off-by: Christophe JAILLET 
> ---
>  drivers/nfc/nfcwilink.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks a lot.

Cheers,
Samuel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] nfc: netlink: avoid NULL pointer dereference on error

[Samuel Ortiz]

Hi Vincent,

On Wed, Oct 07, 2015 at 11:33:19AM +0200, Vincent Stehlé wrote:
> The function nfc_genl_llc_sdreq() can dereference the dev pointer while
> it is NULL on its error path. Create a new error handling label to avoid
> that.
> 
> This fixes the following coccinelle error:
> 
>   ./net/nfc/netlink.c:1175:21-24: ERROR: dev is NULL but dereferenced.
> 
> Signed-off-by: Vincent Stehlé 
> Cc: Thierry Escande 
> Cc: Samuel Ortiz 
> ---
>  net/nfc/netlink.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/net/nfc/netlink.c b/net/nfc/netlink.c
> index 853172c..51c48f0 100644
> --- a/net/nfc/netlink.c
> +++ b/net/nfc/netlink.c
> @@ -,7 +,7 @@ static int nfc_genl_llc_sdreq(struct sk_buff *skb, 
> struct genl_info *info)
>   dev = nfc_get_device(idx);
>   if (!dev) {
>   rc = -ENODEV;
> - goto exit;
> + goto exit_nodev;
>   }
Julia Lawall sent a better fix that I applied:

-   if (!dev) {
-   rc = -ENODEV;
-   goto exit;
-   }
+   if (!dev)
+   return -ENODEV;

Cheers,
Samuel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] NFC: nxp-nci: constify nxp_nci_phy_ops structure

[Samuel Ortiz]

Hi Julia,

On Sun, Oct 11, 2015 at 01:24:13PM +0200, Julia Lawall wrote:
> The only instance of a nxp_nci_phy_ops structure is never modified.  Thus
> the declaration of the structure and all references to the structure type
> can be made const.
> 
> Done with the help of Coccinelle.
> 
> Signed-off-by: Julia Lawall 
> 
> ---
>  drivers/nfc/nxp-nci/core.c|3 ++-
>  drivers/nfc/nxp-nci/i2c.c |2 +-
>  drivers/nfc/nxp-nci/nxp-nci.h |5 +++--
>  3 files changed, 6 insertions(+), 4 deletions(-)
Applied to nfc-next, thanks.

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

Re: [RESEND PATCH] NFC: trf7970a: Add OF match table

[Samuel Ortiz]

Hi Javier,

On Wed, Sep 16, 2015 at 11:08:42AM +0200, Javier Martinez Canillas wrote:
> The Documentation/devicetree/bindings/net/nfc/trf7970a.txt DT binding doc
> lists "ti,trf7970a" as a compatible string but the corresponding driver
> does not have an OF match table. Add the table to the driver so the SPI
> core can do an OF style match.
> 
> Signed-off-by: Javier Martinez Canillas 
> 
> ---
> 
>  drivers/nfc/trf7970a.c | 7 +++
>  1 file changed, 7 insertions(+)
Patch applied, thanks.

Cheers,
Samuel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 5/9] clocksource/drivers/h8300_*: Remove unneeded memset()s

[Yoshinori Sato]

On Tue, 20 Oct 2015 05:59:24 +0900,
Daniel Lezcano wrote:
> 
> From: Alexey Klimov 
> 
> Memory for timer16_priv, timer8_priv and tpu_priv structs is
> allocated by devm_kzalloc() in corresponding probe functions
> of drivers.
> No need to zero it one more time.
> 
> Signed-off-by: Alexey Klimov 
> Signed-off-by: Daniel Lezcano 
Acked-by: Yoshinori Sato 

> ---
>  drivers/clocksource/h8300_timer16.c | 1 -
>  drivers/clocksource/h8300_timer8.c  | 1 -
>  drivers/clocksource/h8300_tpu.c | 1 -
>  3 files changed, 3 deletions(-)
> 
> diff --git a/drivers/clocksource/h8300_timer16.c 
> b/drivers/clocksource/h8300_timer16.c
> index 82941c1..0e076c6 100644
> --- a/drivers/clocksource/h8300_timer16.c
> +++ b/drivers/clocksource/h8300_timer16.c
> @@ -153,7 +153,6 @@ static int timer16_setup(struct timer16_priv *p, struct 
> platform_device *pdev)
>   int ret, irq;
>   unsigned int ch;
>  
> - memset(p, 0, sizeof(*p));
>   p->pdev = pdev;
>  
>   res[REG_CH] = platform_get_resource(p->pdev,
> diff --git a/drivers/clocksource/h8300_timer8.c 
> b/drivers/clocksource/h8300_timer8.c
> index f9b3b70..44375d8 100644
> --- a/drivers/clocksource/h8300_timer8.c
> +++ b/drivers/clocksource/h8300_timer8.c
> @@ -215,7 +215,6 @@ static int timer8_setup(struct timer8_priv *p,
>   int irq;
>   int ret;
>  
> - memset(p, 0, sizeof(*p));
>   p->pdev = pdev;
>  
>   res = platform_get_resource(p->pdev, IORESOURCE_MEM, 0);
> diff --git a/drivers/clocksource/h8300_tpu.c b/drivers/clocksource/h8300_tpu.c
> index 64195fd..5487410 100644
> --- a/drivers/clocksource/h8300_tpu.c
> +++ b/drivers/clocksource/h8300_tpu.c
> @@ -123,7 +123,6 @@ static int __init tpu_setup(struct tpu_priv *p, struct 
> platform_device *pdev)
>  {
>   struct resource *res[2];
>  
> - memset(p, 0, sizeof(*p));
>   p->pdev = pdev;
>  
>   res[CH_L] = platform_get_resource(p->pdev, IORESOURCE_MEM, CH_L);
> -- 
> 1.9.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: build warning after merge of the nfs tree

[Stephen Rothwell]

Hi Trond,

After merging the nfs tree, today's linux-next build (powerpc allyesconfig
produced this warning:

./usr/include/linux/nfs.h:40: found __[us]{8,16,32,64} type without #include 


Introduced by commit

  a340abcf4173 ("nfs42: add NFS_IOC_CLONE_RANGE ioctl")

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

Re: linux-next: bad base of the h8300 tree

[Yoshinori Sato]

On Tue, 20 Oct 2015 06:57:43 +0900,
Stephen Rothwell wrote:
> 
> Hi,
> 
> On Thu, 15 Oct 2015 09:21:57 +1100 Stephen Rothwell  
> wrote:
> >
> > On Sat, 3 Oct 2015 14:28:38 +1000 Stephen Rothwell  
> > wrote:
> > >
> > > It is now based on next-20150925.  As I have said before, you cannot
> > > base your linux-next included branch on a linux-next release.  You
> > > should either base it on Linus' tree, or one of the other linux-next
> > > included branches (as long as that other branch is never rebased).  
> > 
> > OK, now your tree is no longer based on a linux-next release (thanks).
> > However, you have managed to rebase a whole string of post v4.3-rc5
> > commits from Linus' tree into your tree.  This would mean that we would
> > end up with duplicates of those patches.  Please just rebase your
> > patches (and just your patches) onto some part of Linus' tree.
> 
> And now that you have merged in v4.3-rc6, just do a "git rebase
> v4.3-rc6", please (you still have duplicates of some of the patches in
> Linus' tree between -rc5 and -rc6.
> 

OK.
Fixed.

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

-- 
Yoshinori Sato

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

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

[Madhavan Srinivasan]

On Monday 19 October 2015 05:48 PM, Anju T wrote:
> From: Anju 
>
> The registers to sample are passed through the sample_regs_intr bitmask.
> The name and bit position for each register is defined in asm/perf_regs.h.
> This feature can be enabled by using -I option with perf  record command.
> To display the sampled register values use perf script -D.
> The kernel uses the "PERF" register ids to find offset of the register in 
> 'struct pt_regs'.
> CONFIG_HAVE_PERF_REGS will enable sampling of the interrupted machine state.
>
> Signed-off-by: Anju T 
> ---
>  arch/powerpc/Kconfig  |  1 +
>  arch/powerpc/perf/Makefile|  2 +-
>  arch/powerpc/perf/perf_regs.c | 85 
> +++
>  tools/perf/config/Makefile|  4 ++
>  4 files changed, 91 insertions(+), 1 deletion(-)
>  create mode 100644 arch/powerpc/perf/perf_regs.c
>
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 9a7057e..c4ce60d 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -119,6 +119,7 @@ config PPC
>   select GENERIC_ATOMIC64 if PPC32
>   select ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE
>   select HAVE_PERF_EVENTS
> + select HAVE_PERF_REGS
>   select HAVE_REGS_AND_STACK_ACCESS_API
>   select HAVE_HW_BREAKPOINT if PERF_EVENTS && PPC_BOOK3S_64
>   select ARCH_WANT_IPC_PARSE_VERSION
> diff --git a/arch/powerpc/perf/Makefile b/arch/powerpc/perf/Makefile
> index f9c083a..8e7f545 100644
> --- a/arch/powerpc/perf/Makefile
> +++ b/arch/powerpc/perf/Makefile
> @@ -7,7 +7,7 @@ obj64-$(CONFIG_PPC_PERF_CTRS) += power4-pmu.o ppc970-pmu.o 
> power5-pmu.o \
>  power5+-pmu.o power6-pmu.o power7-pmu.o \
>  power8-pmu.o
>  obj32-$(CONFIG_PPC_PERF_CTRS)+= mpc7450-pmu.o
> -
> +obj-$(CONFIG_PERF_EVENTS)+= perf_regs.o
>  obj-$(CONFIG_FSL_EMB_PERF_EVENT) += core-fsl-emb.o
>  obj-$(CONFIG_FSL_EMB_PERF_EVENT_E500) += e500-pmu.o e6500-pmu.o
>
> diff --git a/arch/powerpc/perf/perf_regs.c b/arch/powerpc/perf/perf_regs.c
> new file mode 100644
> index 000..7a71de2
> --- /dev/null
> +++ b/arch/powerpc/perf/perf_regs.c
> @@ -0,0 +1,85 @@
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define PT_REGS_OFFSET(id, r) [id] = offsetof(struct pt_regs, r)
> +
> +#define REG_RESERVED (~((1ULL << PERF_REG_POWERPC_MAX) - 1))
> +
> +static unsigned int pt_regs_offset[PERF_REG_POWERPC_MAX] = {
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR0, gpr[0]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR1, gpr[1]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR2, gpr[2]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR3, gpr[3]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR4, gpr[4]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR5, gpr[5]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR6, gpr[6]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR7, gpr[7]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR8, gpr[8]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR9, gpr[9]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR10, gpr[10]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR11, gpr[11]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR12, gpr[12]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR13, gpr[13]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR14, gpr[14]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR15, gpr[15]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR16, gpr[16]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR17, gpr[17]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR18, gpr[18]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR19, gpr[19]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR20, gpr[20]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR21, gpr[21]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR22, gpr[22]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR23, gpr[23]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR24, gpr[24]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR25, gpr[25]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR26, gpr[26]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR27, gpr[27]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR28, gpr[28]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR29, gpr[29]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR30, gpr[30]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_GPR31, gpr[31]),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_NIP, nip),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_MSR, msr),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_ORIG_R3, orig_gpr3),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_CTR, ctr),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_LNK, link),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_XER, xer),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_CCR, ccr),
> +#ifdef __powerpc64__
> + PT_REGS_OFFSET(PERF_REG_POWERPC_SOFTE, softe),
> +#else
> + PT_REGS_OFFSET(PERF_REG_POWERPC_MQ, mq),
> +#endif
> + PT_REGS_OFFSET(PERF_REG_POWERPC_TRAP, trap),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_DAR, dar),
> + PT_REGS_OFFSET(PERF_REG_POWERPC_DSISR, dsisr),
> + 

Re: [PATCH v4 6/8] drivers: soc: add support for exynos SROM driver

[Krzysztof Kozlowski]

On 20.10.2015 12:46, Pankaj Dubey wrote:
> Hi Krzysztof,
> 
> On Tuesday 20 October 2015 05:40 AM, Krzysztof Kozlowski wrote:
>> On 19.10.2015 20:46, Pankaj Dubey wrote:
>>> This patch adds Exynos SROM controller driver which will handle
>>> save restore of SROM registers during S2R.
>>>
>>> Signed-off-by: Pankaj Dubey 
>>> ---
>>>   drivers/soc/Kconfig   |   1 +
>>>   drivers/soc/Makefile  |   1 +
>>>   drivers/soc/samsung/Kconfig   |  13 +++
>>>   drivers/soc/samsung/Makefile  |   1 +
>>>   drivers/soc/samsung/exynos-srom.c | 179
>>> ++
>>>   drivers/soc/samsung/exynos-srom.h |  51 +++
>>>   6 files changed, 246 insertions(+)
>>>   create mode 100644 drivers/soc/samsung/Kconfig
>>>   create mode 100644 drivers/soc/samsung/Makefile
>>>   create mode 100644 drivers/soc/samsung/exynos-srom.c
>>>   create mode 100644 drivers/soc/samsung/exynos-srom.h
>>>
>>> diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
>>> index 96ddecb..69107c9 100644
>>> --- a/drivers/soc/Kconfig
>>> +++ b/drivers/soc/Kconfig
>>> @@ -2,6 +2,7 @@ menu "SOC (System On Chip) specific Drivers"
>>>
>>>   source "drivers/soc/mediatek/Kconfig"
>>>   source "drivers/soc/qcom/Kconfig"
>>> +source "drivers/soc/samsung/Kconfig"
>>>   source "drivers/soc/sunxi/Kconfig"
>>>   source "drivers/soc/ti/Kconfig"
>>>   source "drivers/soc/versatile/Kconfig"
>>> diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
>>> index 0b12d77..a623616 100644
>>> --- a/drivers/soc/Makefile
>>> +++ b/drivers/soc/Makefile
>>> @@ -5,6 +5,7 @@
>>>   obj-$(CONFIG_MACH_DOVE)+= dove/
>>>   obj-$(CONFIG_ARCH_MEDIATEK)+= mediatek/
>>>   obj-$(CONFIG_ARCH_QCOM)+= qcom/
>>> +obj-$(CONFIG_SOC_SAMSUNG)+= samsung/
>>>   obj-$(CONFIG_ARCH_SUNXI)+= sunxi/
>>>   obj-$(CONFIG_ARCH_TEGRA)+= tegra/
>>>   obj-$(CONFIG_SOC_TI)+= ti/
>>> diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
>>> new file mode 100644
>>> index 000..ea4bc2a
>>> --- /dev/null
>>> +++ b/drivers/soc/samsung/Kconfig
>>> @@ -0,0 +1,13 @@
>>> +#
>>> +# SAMSUNG SoC drivers
>>> +#
>>> +menu "Samsung SOC driver support"
>>> +
>>> +config SOC_SAMSUNG
>>> +bool
>>> +
>>> +config EXYNOS_SROM
>>> +bool
>>> +depends on ARM && ARCH_EXYNOS
>>
>> When !PM then the driver will... do nothing, right? So maybe make it
>> depending on PM so tiny configs would benefit?
>>
> 
> Yes. Currently driver will do nothing if !PM. But as we know Fedin, has
> a plan to extend this driver for auxiliary H/W IP hooked to SROM. So in
> that case this dependency will not be valid as those functionality may
> not be dependent on PM, and we may need to remove it later. So I feel
> better not to add it at first place itself.

AFAIR Fedin was talking about missing functionality, not about adding
the contribution by himself. So he might add it or he might not. I did
not receive any commitments from him. The driver should be "proper" for
the time being (which could mean !PM dependency). If there is a need,
then the dependency will be removed.

> 
>>> +static int exynos_srom_remove(struct platform_device *pdev)
>>> +{
>>> +struct exynos_srom *srom = platform_get_drvdata(pdev);
>>> +
>>> +kfree(srom->reg_offset);
>>> +iounmap(srom->reg_base);
>>> +srom->reg_base = NULL;
>>> +srom->reg_offset = NULL;
>>
>> There is no need anymore for these two NULL-s. It made sense only in
>> previous code when these were global variables. At this point the device
>> callbacks cannot be accessed so NULL-ifying does not change anything.
>>
> 
> Agreed. Will update.
> 

Thanks,
Krzysztof

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

Re: [PATCH 1/3] perf/powerpc:add ability to sample intr machine state in power

[Madhavan Srinivasan]

On Monday 19 October 2015 05:48 PM, Anju T wrote:
> From: Anju 
>
> The enum definition assigns an 'id' to each register in power.

I guess it should be "each register in "struct pt_regs" of arch/powerpc
> The order of these values in the enum definition are based on
> the corresponding macros in arch/powerpc/include/uapi/asm/ptrace.h .
>
> Signed-off-by: Anju T 
> ---
>  arch/powerpc/include/uapi/asm/perf_regs.h | 55 
> +++
>  1 file changed, 55 insertions(+)
>  create mode 100644 arch/powerpc/include/uapi/asm/perf_regs.h
>
> diff --git a/arch/powerpc/include/uapi/asm/perf_regs.h 
> b/arch/powerpc/include/uapi/asm/perf_regs.h
> new file mode 100644
> index 000..b97727c
> --- /dev/null
> +++ b/arch/powerpc/include/uapi/asm/perf_regs.h
> @@ -0,0 +1,55 @@
> +#ifndef _ASM_POWERPC_PERF_REGS_H
> +#define _ASM_POWERPC_PERF_REGS_H
> +
> +enum perf_event_powerpc_regs {
> + PERF_REG_POWERPC_GPR0,
> + PERF_REG_POWERPC_GPR1,
> + PERF_REG_POWERPC_GPR2,
> + PERF_REG_POWERPC_GPR3,
> + PERF_REG_POWERPC_GPR4,
> + PERF_REG_POWERPC_GPR5,
> + PERF_REG_POWERPC_GPR6,
> + PERF_REG_POWERPC_GPR7,
> + PERF_REG_POWERPC_GPR8,
> + PERF_REG_POWERPC_GPR9,
> + PERF_REG_POWERPC_GPR10,
> + PERF_REG_POWERPC_GPR11,
> + PERF_REG_POWERPC_GPR12,
> + PERF_REG_POWERPC_GPR13,
> + PERF_REG_POWERPC_GPR14,
> + PERF_REG_POWERPC_GPR15,
> + PERF_REG_POWERPC_GPR16,
> + PERF_REG_POWERPC_GPR17,
> + PERF_REG_POWERPC_GPR18,
> + PERF_REG_POWERPC_GPR19,
> + PERF_REG_POWERPC_GPR20,
> + PERF_REG_POWERPC_GPR21,
> + PERF_REG_POWERPC_GPR22,
> + PERF_REG_POWERPC_GPR23,
> + PERF_REG_POWERPC_GPR24,
> + PERF_REG_POWERPC_GPR25,
> + PERF_REG_POWERPC_GPR26,
> + PERF_REG_POWERPC_GPR27,
> + PERF_REG_POWERPC_GPR28,
> + PERF_REG_POWERPC_GPR29,
> + PERF_REG_POWERPC_GPR30,
> + PERF_REG_POWERPC_GPR31,
> + PERF_REG_POWERPC_NIP,
> + PERF_REG_POWERPC_MSR,
> + PERF_REG_POWERPC_ORIG_R3,
> + PERF_REG_POWERPC_CTR,
> + PERF_REG_POWERPC_LNK,
> + PERF_REG_POWERPC_XER,
> + PERF_REG_POWERPC_CCR,
> +#ifdef __powerpc64__
> + PERF_REG_POWERPC_SOFTE,
> +#else
> + PERF_REG_POWERPC_MQ,
> +#endif
> + PERF_REG_POWERPC_TRAP,
> + PERF_REG_POWERPC_DAR,
> + PERF_REG_POWERPC_DSISR,
> + PERF_REG_POWERPC_RESULT,
> + PERF_REG_POWERPC_MAX,
> +};
> +#endif /* _ASM_POWERPC_PERF_REGS_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/

Bonded magnets for your Motor

[Thomas]

Dear Sir/Madam,

This is Thomas from topmag,Shenzhen,China.

From your website, we know that our magnet products may be used for your 
products.

Our branch company also manufacture and supply raw materials of high calss 
praseodymium-neodymium-iron alloy, dysprosium, chromium metal etc. We are 
specialized in sintered & bonded NdFeB magnets, SmCo magnets, Alnico magnets, 
ferrite magnets and various kinds of magnetic assemblies.

Looking foward to hearing from you.

Thomas --- Sales Engineer  
Mobile: 0086-15889706837
Address: Dalang street,Longhua district, Shenzhen,PRC 
Tel:86-755-29019871 
E-mail: topm...@163.com

Re: [linux-sunxi] Re: [PATCH 3/6] mfd: axp20x: Add support for RSB based AXP223 PMIC

[Chen-Yu Tsai]

On Tue, Oct 20, 2015 at 2:48 AM, Maxime Ripard
 wrote:
> On Mon, Oct 19, 2015 at 02:20:29PM +0800, Chen-Yu Tsai wrote:
>> On Mon, Oct 19, 2015 at 2:02 PM, Maxime Ripard
>>  wrote:
>> > On Fri, Oct 16, 2015 at 02:46:23PM +0800, Chen-Yu Tsai wrote:
>> >> On Fri, Oct 16, 2015 at 2:41 PM, Maxime Ripard
>> >>  wrote:
>> >> > On Thu, Oct 15, 2015 at 12:32:19AM +0800, Chen-Yu Tsai wrote:
>> >> >> The AXP223 is a new PMIC commonly paired with Allwinner A23/A33 SoCs.
>> >> >> It is functionally identical to AXP221; only the regulator default
>> >> >> voltage/status and the external host interface are different.
>> >> >>
>> >> >> Signed-off-by: Chen-Yu Tsai 
>> >> >> ---
>> >> >>  drivers/mfd/Kconfig| 12 ++
>> >> >>  drivers/mfd/Makefile   |  1 +
>> >> >>  drivers/mfd/axp20x-core.c  |  2 +
>> >> >>  drivers/mfd/axp20x-rsb.c   | 93 
>> >> >> ++
>> >> >>  include/linux/mfd/axp20x.h |  1 +
>> >> >>  5 files changed, 109 insertions(+)
>> >> >>  create mode 100644 drivers/mfd/axp20x-rsb.c
>> >> >>
>> >> >> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
>> >> >> index 9ba3feb3f2fc..6e5edb61d42e 100644
>> >> >> --- a/drivers/mfd/Kconfig
>> >> >> +++ b/drivers/mfd/Kconfig
>> >> >> @@ -84,6 +84,7 @@ config MFD_BCM590XX
>> >> >>  config MFD_AXP20X
>> >> >>   bool "X-Powers AXP series PMICs"
>> >> >>   select MFD_AXP20X_I2C
>> >> >> + select MFD_AXP20X_RSB
>> >> >>
>> >> >>  config MFD_AXP20X_CORE
>> >> >>   bool
>> >> >> @@ -102,6 +103,17 @@ config MFD_AXP20X_I2C
>> >> >> components like regulators or the PEK (Power Enable Key) under 
>> >> >> the
>> >> >> corresponding menus.
>> >> >>
>> >> >> +config MFD_AXP20X_RSB
>> >> >> + bool "X-Powers AXP series RSB PMICs"
>> >> >> + select MFD_AXP20X_CORE
>> >> >> + depends on SUNXI_RSB=y
>> >> >
>> >> > Do we need that? Even if the bus is compiled as a module, the driver
>> >> > will not be probed before that, will it?
>> >>
>> >> There's a compile/link dependency on the __devm_regmap_init_sunxi_rsb().
>> >
>> > If it's exported, everything should be fine, no?
>> >
>> >> And both drivers are bool, i.e. can't be compiled as a module. What we
>> >> don't want is enabling MFD_AXP20X_RSB without SUNXI_RSB.
>> >
>> > What would really be the issue here? The driver wouldn't be probed,
>> > and that's it. Or am I missing something?
>>
>> The RSB bus / slave device functions have been merged into the RSB driver
>> itself. Enabling MFD_AXP20X_RSB without enabling SUNXI_RSB means that RSB
>> bus/device related functions are not compiled, i.e. link error:
>>
>> drivers/built-in.o: In function `axp20x_rsb_probe':
>> /home/wens/sunxi/linux/drivers/mfd/axp20x-rsb.c:64: undefined
>> reference to `__devm_regmap_init_sunxi_rsb'
>> drivers/built-in.o: In function `axp20x_rsb_driver_init':
>> /home/wens/sunxi/linux/drivers/mfd/axp20x-rsb.c:89: undefined
>> reference to `sunxi_rsb_driver_register'
>> Makefile:927: recipe for target 'vmlinux' failed
>>
>> The dependency is like "depends on I2C=y" for the I2C version.
>>
>> If you're asking about why "=y", I guess it's because MFD_AXP20X_RSB is bool,
>> and if the depended on symbol is a tristate, which it actually is for I2c,
>> we'd want it to be compiled in, and not built as a module, or again we'd get
>> a undefined reference link error.
>
> Yeah, but my point was more why not have both the RSB driver and MFD
> as a module? The part where RSB is a module and the driver is
> statically built doesn't make sense (and I don't think a depends on
> allow that), but having both make sense.

Ok. I have no problem with building them as modules. I was just following
what the original driver did.

It seems half the mfd driver can be built as modules, while the other
half can only be built-in. I don't know what the criteria is here.

>> Would it make sense to have SUNXI_RSB as a tristate symbol, i.e. can be built
>> as a module? I'm nore sure. For multi-platform kernels, probably? Currently 
>> it
>> isn't.
>
> Yes, it's better for multi-platform / distro kernels.

I guess I'll do a follow up patch for sunxi-rsb?

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

Re: [PATCH tip/locking/core v8 1/5] locking/qspinlock: Use _acquire/_release versions of cmpxchg & xchg

[Boqun Feng]

On Mon, Oct 19, 2015 at 08:46:02PM -0700, Davidlohr Bueso wrote:
> On Tue, 20 Oct 2015, Boqun Feng wrote:
> 
> >>@@ -93,7 +94,7 @@ static __always_inline void queued_spin_unlock(struct 
> >>qspinlock *lock)
> >>/*
> >> * smp_mb__before_atomic() in order to guarantee release semantics
> >> */
> >>-   smp_mb__before_atomic_dec();
> >>+   smp_mb__before_atomic();
> >>atomic_sub(_Q_LOCKED_VAL, >val);
> >
> >Just be curious, you don't use atomic_sub_release() here on purpose?
> 
> atomic_sub() does not imply barriers, so there's no relaxed variants; that's
> only for _return() (and such) to the caller.
> 

Ah.. my mistake ;-(

Thank you.

Regards,
Boqun

> Thanks,
> Davidlohr




signature.asc
Description: PGP signature

Re: [PATCH v4 6/8] drivers: soc: add support for exynos SROM driver

[Pankaj Dubey]

Hi Krzysztof,

On Tuesday 20 October 2015 05:40 AM, Krzysztof Kozlowski wrote:

On 19.10.2015 20:46, Pankaj Dubey wrote:

This patch adds Exynos SROM controller driver which will handle
save restore of SROM registers during S2R.

Signed-off-by: Pankaj Dubey 
---
  drivers/soc/Kconfig   |   1 +
  drivers/soc/Makefile  |   1 +
  drivers/soc/samsung/Kconfig   |  13 +++
  drivers/soc/samsung/Makefile  |   1 +
  drivers/soc/samsung/exynos-srom.c | 179 ++
  drivers/soc/samsung/exynos-srom.h |  51 +++
  6 files changed, 246 insertions(+)
  create mode 100644 drivers/soc/samsung/Kconfig
  create mode 100644 drivers/soc/samsung/Makefile
  create mode 100644 drivers/soc/samsung/exynos-srom.c
  create mode 100644 drivers/soc/samsung/exynos-srom.h

diff --git a/drivers/soc/Kconfig b/drivers/soc/Kconfig
index 96ddecb..69107c9 100644
--- a/drivers/soc/Kconfig
+++ b/drivers/soc/Kconfig
@@ -2,6 +2,7 @@ menu "SOC (System On Chip) specific Drivers"

  source "drivers/soc/mediatek/Kconfig"
  source "drivers/soc/qcom/Kconfig"
+source "drivers/soc/samsung/Kconfig"
  source "drivers/soc/sunxi/Kconfig"
  source "drivers/soc/ti/Kconfig"
  source "drivers/soc/versatile/Kconfig"
diff --git a/drivers/soc/Makefile b/drivers/soc/Makefile
index 0b12d77..a623616 100644
--- a/drivers/soc/Makefile
+++ b/drivers/soc/Makefile
@@ -5,6 +5,7 @@
  obj-$(CONFIG_MACH_DOVE)   += dove/
  obj-$(CONFIG_ARCH_MEDIATEK)   += mediatek/
  obj-$(CONFIG_ARCH_QCOM)   += qcom/
+obj-$(CONFIG_SOC_SAMSUNG)  += samsung/
  obj-$(CONFIG_ARCH_SUNXI)  += sunxi/
  obj-$(CONFIG_ARCH_TEGRA)  += tegra/
  obj-$(CONFIG_SOC_TI)  += ti/
diff --git a/drivers/soc/samsung/Kconfig b/drivers/soc/samsung/Kconfig
new file mode 100644
index 000..ea4bc2a
--- /dev/null
+++ b/drivers/soc/samsung/Kconfig
@@ -0,0 +1,13 @@
+#
+# SAMSUNG SoC drivers
+#
+menu "Samsung SOC driver support"
+
+config SOC_SAMSUNG
+   bool
+
+config EXYNOS_SROM
+   bool
+   depends on ARM && ARCH_EXYNOS


When !PM then the driver will... do nothing, right? So maybe make it
depending on PM so tiny configs would benefit?



Yes. Currently driver will do nothing if !PM. But as we know Fedin, has 
a plan to extend this driver for auxiliary H/W IP hooked to SROM. So in 
that case this dependency will not be valid as those functionality may 
not be dependent on PM, and we may need to remove it later. So I feel 
better not to add it at first place itself.




+static int exynos_srom_remove(struct platform_device *pdev)
+{
+   struct exynos_srom *srom = platform_get_drvdata(pdev);
+
+   kfree(srom->reg_offset);
+   iounmap(srom->reg_base);
+   srom->reg_base = NULL;
+   srom->reg_offset = NULL;


There is no need anymore for these two NULL-s. It made sense only in
previous code when these were global variables. At this point the device
callbacks cannot be accessed so NULL-ifying does not change anything.



Agreed. Will update.


Rest from my point of view looks good.



Thanks for review.

Pankaj


Best regards,
Krzysztof



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

Re: [PATCH tip/locking/core v8 1/5] locking/qspinlock: Use _acquire/_release versions of cmpxchg & xchg

[Davidlohr Bueso]

On Tue, 20 Oct 2015, Boqun Feng wrote:


@@ -93,7 +94,7 @@ static __always_inline void queued_spin_unlock(struct 
qspinlock *lock)
/*
 * smp_mb__before_atomic() in order to guarantee release semantics
 */
-   smp_mb__before_atomic_dec();
+   smp_mb__before_atomic();
atomic_sub(_Q_LOCKED_VAL, >val);


Just be curious, you don't use atomic_sub_release() here on purpose?


atomic_sub() does not imply barriers, so there's no relaxed variants; that's
only for _return() (and such) to the caller.

Thanks,
Davidlohr

signature.asc
Description: Digital signature

Re: [PATCH 1/2] serial: support register interface with 16-bit stride for console

[Masahiro Yamada]

Hi Peter,

2015-10-20 4:50 GMT+09:00 Peter Hurley :
> On 10/19/2015 01:40 AM, Masahiro Yamada wrote:
>> Currently, 8-bit (MMIO) and 32-bit (MMIO32) strides are supported for
>> the 8250 console, but 16-bit (MMIO16) stride is not.  The 8250 UART
>> device on my board has 16-bit stride (reg-shift = <1>) and I am eager
>> to use earlycon with it.
>>
>> Refer to arch/arm/boot/dts/uniphier-support-card.dtsi:
>>
>> serialsc: uart@000b {
>> compatible = "ns16550a";
>> reg = <0x000b 0x20>;
>> clock-frequency = <12288000>;
>> reg-shift = <1>;
>> };
>>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>>  Documentation/kernel-parameters.txt  |  9 +
>>  drivers/tty/serial/8250/8250_early.c |  5 +
>>  drivers/tty/serial/8250/8250_port.c  | 20 
>>  drivers/tty/serial/earlycon.c| 15 +++
>>  drivers/tty/serial/serial_core.c |  9 +++--
>>  include/linux/serial_core.h  |  1 +
>>  include/uapi/linux/serial.h  |  9 +
>>  7 files changed, 54 insertions(+), 14 deletions(-)
>>
>
> [...]
>
>> diff --git a/include/uapi/linux/serial.h b/include/uapi/linux/serial.h
>> index 25331f9..1d20d9c 100644
>> --- a/include/uapi/linux/serial.h
>> +++ b/include/uapi/linux/serial.h
>> @@ -65,10 +65,11 @@ struct serial_struct {
>>  #define SERIAL_IO_PORT   0
>>  #define SERIAL_IO_HUB6   1
>>  #define SERIAL_IO_MEM2
>> -#define SERIAL_IO_MEM323
>> -#define SERIAL_IO_AU   4
>> -#define SERIAL_IO_TSI  5
>> -#define SERIAL_IO_MEM32BE 6
>> +#define SERIAL_IO_MEM16  3
>> +#define SERIAL_IO_MEM324
>> +#define SERIAL_IO_AU   5
>> +#define SERIAL_IO_TSI  6
>> +#define SERIAL_IO_MEM32BE 7
>
> The existing values cannot be re-defined since they're userspace visible.

Thanks, I've sent v2.


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

[PATCH v2 1/2] serial: support register interface with 16-bit stride for console

[Masahiro Yamada]

Currently, 8-bit (MMIO) and 32-bit (MMIO32) register strides are
supported for the 8250 console, but 16-bit (MMIO16) stride is not.
The 8250 UART device on my board is connected to a 16-bit bus
(reg-shift = <1>) and I am eager to use earlycon with it.

Refer to arch/arm/boot/dts/uniphier-support-card.dtsi:

serialsc: uart@000b {
compatible = "ns16550a";
reg = <0x000b 0x20>;
clock-frequency = <12288000>;
reg-shift = <1>;
};

Signed-off-by: Masahiro Yamada 
---

Changes in v2:
  - Do not change userspace-exported macros

 Documentation/kernel-parameters.txt  |  9 +
 drivers/tty/serial/8250/8250_early.c |  5 +
 drivers/tty/serial/8250/8250_port.c  | 20 
 drivers/tty/serial/earlycon.c| 15 +++
 drivers/tty/serial/serial_core.c |  9 +++--
 include/linux/serial_core.h  |  1 +
 include/uapi/linux/serial.h  |  1 +
 7 files changed, 50 insertions(+), 10 deletions(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 22a4b68..761f08c 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -720,16 +720,17 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
 
uart[8250],io,[,options]
uart[8250],mmio,[,options]
+   uart[8250],mmio16,[,options]
uart[8250],mmio32,[,options]
uart[8250],0x[,options]
Start an early, polled-mode console on the 8250/16550
UART at the specified I/O port or MMIO address,
switching to the matching ttyS device later.
MMIO inter-register address stride is either 8-bit
-   (mmio) or 32-bit (mmio32).
-   If none of [io|mmio|mmio32],  is assumed to be
-   equivalent to 'mmio'. 'options' are specified in the
-   same format described for ttyS above; if unspecified,
+   (mmio), 16-bit (mmio16), or 32-bit (mmio32).
+   If none of [io|mmio|mmio16|mmio32],  is assumed
+   to be equivalent to 'mmio'. 'options' are specified in
+   the same format described for ttyS above; if 
unspecified,
the h/w is not re-initialized.
 
hvc  Use the hypervisor console device . This is for
diff --git a/drivers/tty/serial/8250/8250_early.c 
b/drivers/tty/serial/8250/8250_early.c
index faed05f..7aff3d8 100644
--- a/drivers/tty/serial/8250/8250_early.c
+++ b/drivers/tty/serial/8250/8250_early.c
@@ -40,6 +40,8 @@ static unsigned int __init serial8250_early_in(struct 
uart_port *port, int offse
switch (port->iotype) {
case UPIO_MEM:
return readb(port->membase + offset);
+   case UPIO_MEM16:
+   return readw(port->membase + (offset << 1));
case UPIO_MEM32:
return readl(port->membase + (offset << 2));
case UPIO_MEM32BE:
@@ -57,6 +59,9 @@ static void __init serial8250_early_out(struct uart_port 
*port, int offset, int
case UPIO_MEM:
writeb(value, port->membase + offset);
break;
+   case UPIO_MEM16:
+   writew(value, port->membase + (offset << 1));
+   break;
case UPIO_MEM32:
writel(value, port->membase + (offset << 2));
break;
diff --git a/drivers/tty/serial/8250/8250_port.c 
b/drivers/tty/serial/8250/8250_port.c
index 0bbf340..f976948 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -368,6 +368,18 @@ static void mem_serial_out(struct uart_port *p, int 
offset, int value)
writeb(value, p->membase + offset);
 }
 
+static void mem16_serial_out(struct uart_port *p, int offset, int value)
+{
+   offset = offset << p->regshift;
+   writew(value, p->membase + offset);
+}
+
+static unsigned int mem16_serial_in(struct uart_port *p, int offset)
+{
+   offset = offset << p->regshift;
+   return readw(p->membase + offset);
+}
+
 static void mem32_serial_out(struct uart_port *p, int offset, int value)
 {
offset = offset << p->regshift;
@@ -425,6 +437,11 @@ static void set_io_from_upio(struct uart_port *p)
p->serial_out = mem_serial_out;
break;
 
+   case UPIO_MEM16:
+   p->serial_in = mem16_serial_in;
+   p->serial_out = mem16_serial_out;
+   break;
+
case UPIO_MEM32:
p->serial_in = mem32_serial_in;
p->serial_out = mem32_serial_out;
@@ -459,6 +476,7 @@ serial_port_out_sync(struct uart_port *p, int offset, int 
value)
 {
switch (p->iotype) {
case UPIO_MEM:
+   case UPIO_MEM16:
case UPIO_MEM32:
case 

[PATCH v2 0/2] serial: console: add two features

[Masahiro Yamada]

1/2: add MMIO16 register interface support
2/2: allow to input clock frequency from kernel parameter


Changes in v2:
  - Do not change userspace-exported macros

Masahiro Yamada (2):
  serial: support register interface with 16-bit stride for console
  serial: earlycon: allow to specify uartclk in earlycon
kernel-parameter

 Documentation/kernel-parameters.txt  |  9 +
 drivers/tty/serial/8250/8250_early.c |  5 +
 drivers/tty/serial/8250/8250_port.c  | 20 
 drivers/tty/serial/earlycon.c| 23 ++-
 drivers/tty/serial/serial_core.c |  9 +++--
 include/linux/serial_core.h  |  1 +
 include/uapi/linux/serial.h  |  1 +
 7 files changed, 57 insertions(+), 11 deletions(-)

-- 
1.9.1

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

[PATCH v2 2/2] serial: earlycon: allow to specify uartclk in earlycon kernel-parameter

[Masahiro Yamada]

The input clock frequency varies from device to device, but the
earlycon uses the fixed frequency (BASE_BAUD * 16).  It makes
impossible to set the correct divisor to the register.

This commit allows to specify the input clock frequency from the
kernel-parameter.

[Example]

earlycon=uart8250,mmio32,0x43fb,115200,12288000

The input clock frequency (12288000, in this case) should be specified
after the baudrate.  If not specified, the default (BASE_BAUD * 16) is
used.

Signed-off-by: Masahiro Yamada 
---

Changes in v2: None

 drivers/tty/serial/earlycon.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
index 07f7393..8030765 100644
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -95,6 +95,13 @@ static int __init parse_options(struct earlycon_device 
*device, char *options)
length = min(strcspn(options, " ") + 1,
 (size_t)(sizeof(device->options)));
strlcpy(device->options, options, length);
+   options = strchr(options, ',');
+   if (options) {
+   options++;
+   port->uartclk = simple_strtoul(options, NULL, 0);
+   }
+   if (!port->uartclk)
+   port->uartclk = BASE_BAUD * 16;
}
 
if (port->iotype == UPIO_MEM || port->iotype == UPIO_MEM16 ||
@@ -122,7 +129,6 @@ static int __init register_earlycon(char *buf, const struct 
earlycon_id *match)
if (buf && !parse_options(_console_dev, buf))
buf = NULL;
 
-   port->uartclk = BASE_BAUD * 16;
if (port->mapbase)
port->membase = earlycon_map(port->mapbase, 64);
 
-- 
1.9.1

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

Re: [RFC PATCH] qspinlock: Improve performance by reducing load instruction rollback

[Ling Ma]

2015-10-19 17:46 GMT+08:00 Peter Zijlstra :
> On Mon, Oct 19, 2015 at 10:27:22AM +0800, ling.ma.prog...@gmail.com wrote:
>> From: Ma Ling 
>>
>> All load instructions can run speculatively but they have to follow
>> memory order rule in multiple cores as below:
>> _x = _y = 0
>>
>> Processor 0   Processor 1
>>
>> mov r1, [ _y]  //M1   mov [ _x], 1  //M3
>> mov r2, [ _x]  //M2   mov [ _y], 1  //M4
>>
>> If r1 = 1, r2 must be 1
>>
>> In order to guarantee above rule, although Processor 0 execute
>> M1 and M2 instruction out of order, they are kept in ROB,
>> when load buffer for _x in Processor 0 received the update
>> message from Processor 1, Processor 0 need to roll back
>> from M2 instruction, which will flush the whole pipeline,
>> the latency is over the penalty from branch prediction miss.
>>
>> In this patch we use lock cmpxchg instruction to force load
>
> "lock cmpxchg" makes me think you're working on x86.
>
>> instructions to be serialization,
>
> smp_rmb() does that, and that's 'free' on x86. Because x86 doesn't do
> read reordering.
>
>> the destination operand
>> receives a write cycle without regard to the result of
>> the comparison, which can help us to reduce the penalty
>> from load instruction roll back.
>
> And that makes me think I'm not understanding what you're getting at. If
> you need to force memory order, a "fence" (or smp_mb()) would still be
> cheaper than endlessly pulling the line into exclusive state for no
> reason, right?

Peter,

we tested instruction lfence, but we hard to see any benefit, lfence
only force load instruction ,
but load instruction still will rollback ,actually cmpxchg behavior is
more like write operation,
so we choose it.

Thanks
Ling
>
>> Our experiment indicates the performance can be improved by 10%~15%
>> for 2 and 3 threads cases, the conflicts from lock cache line
>> spend them most of the time.
>
> That just doesn't parse, what?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH tip/locking/core v8 1/5] locking/qspinlock: Use _acquire/_release versions of cmpxchg & xchg

[Boqun Feng]

Hi Waiman,

On Thu, Oct 15, 2015 at 06:51:03PM -0400, Waiman Long wrote:
> This patch replaces the cmpxchg() and xchg() calls in the native
> qspinlock code with the more relaxed _acquire or _release versions of
> those calls to enable other architectures to adopt queued spinlocks
> with less memory barrier performance overhead.
> 
> Signed-off-by: Waiman Long 
> ---
>  include/asm-generic/qspinlock.h |9 +
>  kernel/locking/qspinlock.c  |   29 -
>  2 files changed, 29 insertions(+), 9 deletions(-)
> 
> diff --git a/include/asm-generic/qspinlock.h b/include/asm-generic/qspinlock.h
> index e2aadbc..39e1cb2 100644
> --- a/include/asm-generic/qspinlock.h
> +++ b/include/asm-generic/qspinlock.h
> @@ -12,8 +12,9 @@
>   * GNU General Public License for more details.
>   *
>   * (C) Copyright 2013-2015 Hewlett-Packard Development Company, L.P.
> + * (C) Copyright 2015 Hewlett-Packard Enterprise Development LP
>   *
> - * Authors: Waiman Long 
> + * Authors: Waiman Long 
>   */
>  #ifndef __ASM_GENERIC_QSPINLOCK_H
>  #define __ASM_GENERIC_QSPINLOCK_H
> @@ -62,7 +63,7 @@ static __always_inline int queued_spin_is_contended(struct 
> qspinlock *lock)
>  static __always_inline int queued_spin_trylock(struct qspinlock *lock)
>  {
>   if (!atomic_read(>val) &&
> -(atomic_cmpxchg(>val, 0, _Q_LOCKED_VAL) == 0))
> +(atomic_cmpxchg_acquire(>val, 0, _Q_LOCKED_VAL) == 0))
>   return 1;
>   return 0;
>  }
> @@ -77,7 +78,7 @@ static __always_inline void queued_spin_lock(struct 
> qspinlock *lock)
>  {
>   u32 val;
>  
> - val = atomic_cmpxchg(>val, 0, _Q_LOCKED_VAL);
> + val = atomic_cmpxchg_acquire(>val, 0, _Q_LOCKED_VAL);
>   if (likely(val == 0))
>   return;
>   queued_spin_lock_slowpath(lock, val);
> @@ -93,7 +94,7 @@ static __always_inline void queued_spin_unlock(struct 
> qspinlock *lock)
>   /*
>* smp_mb__before_atomic() in order to guarantee release semantics
>*/
> - smp_mb__before_atomic_dec();
> + smp_mb__before_atomic();
>   atomic_sub(_Q_LOCKED_VAL, >val);

Just be curious, you don't use atomic_sub_release() here on purpose?

Regards,
Boqun

>  }
>  #endif


signature.asc
Description: PGP signature

Re: [RFC PATCH] qspinlock: Improve performance by reducing load instruction rollback

[Ling Ma]

2015-10-20 1:18 GMT+08:00 Waiman Long :
> On 10/18/2015 10:27 PM, ling.ma.prog...@gmail.com wrote:
>>
>> From: Ma Ling
>>
>> All load instructions can run speculatively but they have to follow
>> memory order rule in multiple cores as below:
>> _x = _y = 0
>>
>> Processor 0 Processor 1
>>
>> mov r1, [ _y]  //M1 mov [ _x], 1  //M3
>> mov r2, [ _x]  //M2 mov [ _y], 1  //M4
>>
>> If r1 = 1, r2 must be 1
>>
>> In order to guarantee above rule, although Processor 0 execute
>> M1 and M2 instruction out of order, they are kept in ROB,
>> when load buffer for _x in Processor 0 received the update
>> message from Processor 1, Processor 0 need to roll back
>> from M2 instruction, which will flush the whole pipeline,
>> the latency is over the penalty from branch prediction miss.
>>
>> In this patch we use lock cmpxchg instruction to force load
>> instructions to be serialization, the destination operand
>> receives a write cycle without regard to the result of
>> the comparison, which can help us to reduce the penalty
>> from load instruction roll back.
>>
>> Our experiment indicates the performance can be improved by 10%~15%
>> for 2 and 3 threads cases, the conflicts from lock cache line
>> spend them most of the time.
>
>
> What kind of performance test were you running? With the right timing, it is
> possible that you see some performance gain. However, if the lock hold time
> is longer so that a fair number of cmpxchg instructions have to be executed
> before it can get the lock, you may see a performance degradation especially
> if the lock holder needs to access the lock cacheline.
>
> In general, we try to avoid this kind of cmpxchg loop unless we are sure
> that at most a few iterations of the loop may happen.

Waiman,

The machine is Haswell (2699 V3, COD off, HT on, 2 sockets)
(we have sent test module in separate email)



A.  Data is located with lock in one cache line On 2 threads cases
(only write struct member data_a)

 1.   Load version test 5 times, the cost time is below:


[root@localhost spinlock]# insmod dummy.ko; rmmod dummy;dmesg -c



 all cost time is 103904620

[root@localhost spinlock]# insmod dummy.ko; rmmod dummy;dmesg -c



 all cost time is 104351876

[root@localhost spinlock]# insmod dummy.ko; rmmod dummy;dmesg -c



 all cost time is 118599784

[root@localhost spinlock]# insmod dummy.ko; rmmod dummy;dmesg -c



 all cost time is 103064024

[root@localhost spinlock]# insmod dummy.ko; rmmod dummy;dmesg -c



 all cost time is 103389696

Totally cost time is 53331

2.   Lock cmpxchg version test 5 times, the cost time is below:

[root@localhost spinlock]# insmod dummy.ko; rmmod dummy;dmesg -c



 all cost time is 67081220

[root@localhost spinlock]# insmod dummy.ko; rmmod dummy;dmesg -c



 all cost time is 97640708

[root@localhost spinlock]# insmod dummy.ko; rmmod dummy;dmesg -c



 all cost time is 96439612

[root@localhost spinlock]# insmod dummy.ko; rmmod dummy;dmesg -c



 all cost time is 66699296

[root@localhost spinlock]# insmod dummy.ko; rmmod dummy;dmesg -c



 all cost time is 96464800



Totally cost time is 424325636



Above data shows lock cmpxchg is better about average 25% (53331/424325636)



B.  Data is located with lock in different cache line On 2 threads
cases(only write struct member data_b)



1.   Load version test 5 times, the cost time is below:



[root@localhost spinlock]# insmod dummy.ko; rmmod dummy;dmesg -c



 all cost time is 174266128

[root@localhost spinlock]# insmod dummy.ko; rmmod dummy;dmesg -c



 all cost time is 205053924

[root@localhost spinlock]# insmod dummy.ko; rmmod dummy;dmesg -c



 all cost time is 160165124

[root@localhost spinlock]# insmod dummy.ko; rmmod dummy;dmesg -c



 all cost time is 173241552

[root@localhost spinlock]# insmod dummy.ko; rmmod dummy;dmesg -c



 all cost time is 205765008

Totally cost time is 918491736



2.   Lock cmpxchg version test 5 times, the cost time is below:

[root@localhost spinlock]# insmod dummy.ko; rmmod dummy;dmesg -c



 all cost time is 113410044

[root@localhost spinlock]# insmod dummy.ko; rmmod dummy;dmesg -c



 all cost time is 116293104

[root@localhost spinlock]# insmod dummy.ko; rmmod dummy;dmesg -c



 all cost time is 116064256

[root@localhost spinlock]# insmod dummy.ko; rmmod dummy;dmesg -c



 all cost time is 189320876

[root@localhost spinlock]# insmod dummy.ko; rmmod dummy;dmesg -c



 all cost time is 123735352

Totally cost time is 658823632



Above data shows lock cmpxchg is better about average 39%  (918491736/658823632)




>
>>
>> Thanks
>> Ling
>>
>> Signed-off-by: Ma Ling
>> ---
>>   kernel/locking/qspinlock.c |   43
>> ++-
>>   1 files changed, 18 insertions(+), 25 deletions(-)
>>
>> diff --git a/kernel/locking/qspinlock.c b/kernel/locking/qspinlock.c
>> index 87e9ce6..16421f2 100644
>> --- a/kernel/locking/qspinlock.c
>> +++ 

Re: [PATCH 2/3] mm/hugetlb: Setup hugetlb_falloc during fallocate hole punch

[Mike Kravetz]

On 10/19/2015 07:22 PM, Hugh Dickins wrote:
> On Mon, 19 Oct 2015, Mike Kravetz wrote:
>> On 10/19/2015 04:16 PM, Andrew Morton wrote:
>>> On Fri, 16 Oct 2015 15:08:29 -0700 Mike Kravetz  
>>> wrote:
>>
mutex_lock(>i_mutex);
 +
 +  spin_lock(>i_lock);
 +  inode->i_private = _falloc;
 +  spin_unlock(>i_lock);
>>>
>>> Locking around a single atomic assignment is a bit peculiar.  I can
>>> kinda see that it kinda protects the logic in hugetlb_fault(), but I
>>> would like to hear (in comment form) your description of how this logic
>>> works?
>>
>> To be honest, this code/scheme was copied from shmem as it addresses
>> the same situation there.  I did not notice how strange this looks until
>> you pointed it out.  At first glance, the locking does appear to be
>> unnecessary.  The fault code initially checks this value outside the
>> lock.  However, the fault code (on another CPU) will take the lock
>> and access values within the structure.  Without the locking or some other
>> type of memory barrier here, there is no guarantee that the structure
>> will be initialized before setting i_private.  So, the faulting code
>> could see invalid values in the structure.
>>
>> Hugh, is that accurate?  You provided the shmem code.
> 
> Yes, I think that's accurate; but confess I'm replying now for the
> sake of replying in a rare timely fashion, before having spent any
> time looking through your hugetlbfs reimplementation of the same.
> 
> The peculiar thing in the shmem case, was that the structure being
> pointed to is on the kernel stack of the fallocating task (with
> i_mutex guaranteeing only one at a time per file could be doing this):
> so the faulting end has to be careful that it's not accessing the
> stale memory after the fallocator has retreated back up its stack.

I used the same code/scheme for hugetlbfs.

> And in the shmem case, this "temporary inode extension" also had to
> communicate to shmem_writepage(), the swapout end of things.  Which
> is not a complication you have with hugetlbfs: perhaps it could be
> simpler if just between fallocate and fault, or perhaps not.

Yes, I think it is simpler.  At first I was excited because hugetlbfs
already has a table of mutex'es to synchronize page faults. and I
thought about using those.  If the hole being punched is small this
works fine.  But, for large holes you could end up taking all mutexes
and prevent all huge page faults. :(  So, I went back to the scheme
employed by shmem.

> Whilst it does all work for tmpfs, it looks as if tmpfs was ahead of
> the pack (or trinity was attacking tmpfs before other filesystems),
> and the issue of faulting versus holepunching (and DAX) has captured
> wider interest recently, with Dave Chinner formulating answers in XFS,
> and hoping to set an example for other filesystems.
> 
> If that work were further along, and if I had had time to digest any
> of what he is doing about it, I would point you in his direction rather
> than this; but since this does work for tmpfs, I shouldn't discourage you.
> 
> I'll try to take a look through yours in the coming days, but there's
> several other patchsets I need to look through too, plus a few more
> patches from me, if I can find time to send them in: juggling priorities.
> 
> Hugh

Thanks, and no hurry.  I need to add a little more code to this this patch
set to completely handle the race.  A new patch will be out in a day or two.

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

[PATCH v2 02/10] hwmon: (fam15h_power) Enable power1_input on AMD Carrizo

[Huang Rui]

This patch enables power1_input attribute for Carrizo platform.

Signed-off-by: Huang Rui 
Cc: Borislav Petkov 
Cc: Guenter Roeck 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
---
 drivers/hwmon/fam15h_power.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
index 41d022e..a090adf 100644
--- a/drivers/hwmon/fam15h_power.c
+++ b/drivers/hwmon/fam15h_power.c
@@ -115,8 +115,11 @@ static int fam15h_power_init_attrs(struct pci_dev *pdev,
 {
int n = FAM15H_MIN_NUM_ATTRS;
struct attribute **fam15h_power_attrs;
+   struct cpuinfo_x86 *c = _cpu_data;
 
-   if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model <= 0xf)
+   if (c->x86 == 0x15 &&
+   ((c->x86_model <= 0xf) ||
+(c->x86_model >= 0x60 && c->x86_model <= 0x6f)))
n += 1;
 
fam15h_power_attrs = devm_kcalloc(>dev, n,
@@ -128,7 +131,9 @@ static int fam15h_power_init_attrs(struct pci_dev *pdev,
 
n = 0;
fam15h_power_attrs[n++] = _attr_power1_crit.attr;
-   if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model <= 0xf)
+   if (c->x86 == 0x15 &&
+   ((c->x86_model <= 0xf) ||
+(c->x86_model >= 0x60 && c->x86_model <= 0x6f)))
fam15h_power_attrs[n++] = _attr_power1_input.attr;
 
data->fam15h_power_group.attrs = fam15h_power_attrs;
-- 
1.9.1

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

[PATCH v2 08/10] hwmon: (fam15h_power) Add documentation for previous TDP reporting

[Huang Rui]

This patch adds description to explain the TDP reporting mechanism of
fam15h_power driver.

Signed-off-by: Huang Rui 
Cc: Borislav Petkov 
Cc: Guenter Roeck 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
---
 Documentation/hwmon/fam15h_power | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/Documentation/hwmon/fam15h_power b/Documentation/hwmon/fam15h_power
index e2b1b69..42bf04e 100644
--- a/Documentation/hwmon/fam15h_power
+++ b/Documentation/hwmon/fam15h_power
@@ -10,14 +10,22 @@ Supported chips:
   Datasheets:
   BIOS and Kernel Developer's Guide (BKDG) For AMD Family 15h Processors
   BIOS and Kernel Developer's Guide (BKDG) For AMD Family 16h Processors
+  AMD64 Architecture Programmer's Manual Volume 2: System Programming
 
 Author: Andreas Herrmann 
 
 Description
 ---
 
+1) Processor TDP (Thermal design power)
+
+Given a fixed frequency and voltage, the power consumption of a
+processor varies based on the workload being executed. Derated power
+is the power consumed when running a specific application. Thermal
+design power (TDP) is an example of derated power.
+
 This driver permits reading of registers providing power information
-of AMD Family 15h and 16h processors.
+of AMD Family 15h and 16h processors via TDP algorithm.
 
 For AMD Family 15h and 16h processors the following power values can
 be calculated using different processor northbridge function
-- 
1.9.1

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

Re: [RFC PATCH] qspinlock: Improve performance by reducing load instruction rollback

[Ling Ma]

2015-10-19 17:46 GMT+08:00 Peter Zijlstra :
> On Mon, Oct 19, 2015 at 10:27:22AM +0800, ling.ma.prog...@gmail.com wrote:
>> From: Ma Ling 
>>
>> All load instructions can run speculatively but they have to follow
>> memory order rule in multiple cores as below:
>> _x = _y = 0
>>
>> Processor 0   Processor 1
>>
>> mov r1, [ _y]  //M1   mov [ _x], 1  //M3
>> mov r2, [ _x]  //M2   mov [ _y], 1  //M4
>>
>> If r1 = 1, r2 must be 1
>>
>> In order to guarantee above rule, although Processor 0 execute
>> M1 and M2 instruction out of order, they are kept in ROB,
>> when load buffer for _x in Processor 0 received the update
>> message from Processor 1, Processor 0 need to roll back
>> from M2 instruction, which will flush the whole pipeline,
>> the latency is over the penalty from branch prediction miss.
>>
>> In this patch we use lock cmpxchg instruction to force load
>
> "lock cmpxchg" makes me think you're working on x86.
>
>> instructions to be serialization,
>
> smp_rmb() does that, and that's 'free' on x86. Because x86 doesn't do
> read reordering.
>
>> the destination operand
>> receives a write cycle without regard to the result of
>> the comparison, which can help us to reduce the penalty
>> from load instruction roll back.
>
> And that makes me think I'm not understanding what you're getting at. If
> you need to force memory order, a "fence" (or smp_mb()) would still be
> cheaper than endlessly pulling the line into exclusive state for no
> reason, right?
>
>> Our experiment indicates the performance can be improved by 10%~15%
>> for 2 and 3 threads cases, the conflicts from lock cache line
>> spend them most of the time.
>
> That just doesn't parse, what?
When the thread number is 2 or 3, only lock cache line will generate conflicts,
and cost them the most of the time.

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

[PATCH v2 00/10] hwmon: (fam15h_power) Introduce an accumulated power reporting algorithm

[Huang Rui]

Hi all,

This serial of patches introduces an accumulated power reporting
algorithm. It will calculate the average power consumption for the
processor. The cpu feature flag is CPUID.8000_0007H:EDX[12].

This algorithm is used to test the comparison of processor power
consumption with between MWAITX delay and TSC delay on AMD Carrizo
platforms.

Reference:
http://marc.info/?l=linux-kernel=143874573111310=2

Commit f96756 at tip ("x86/asm: Add MONITORX/MWAITX instruction support")
Commit b466bd at tip ("x86/asm/delay: Introduce an MWAITX-based delay with a 
configurable timer")

V1: http://marc.info/?l=linux-kernel=144066380613299=2

Changes from v1 -> v2:
- Move fam15h_power_groups and fam15h_power_group into fam15h_power_data to
  avoid overwrite on multi-CPU system.
- Rename FAM15H_MIN_NUM_ATTRS macro and fix return error code.
- Remove unnecessary warning print.
- Adds do_read_registers_on_cu to do all the read to all MSRs and run it on one
  of the online cores on each compute unit with smp_call_function_many().
- Use power1_average and power1_average_interval standard entry
  instread of power1_acc
- Fix the CPU-hotplug case.

A simple example:

ray@hr-ub:~/tip$ sensors
fam15h_power-pci-00c4
Adapter: PCI adapter
power1:   23.73 mW (avg = 634.63 mW, interval =   0.01 s)
   (crit =  15.00 W)

...

These patches are rebased on groeck/hwmon-next.

Thanks,
Rui

Huang Rui (10):
  hwmon: (fam15h_power) Refactor attributes for dynamically added
  hwmon: (fam15h_power) Enable power1_input on AMD Carrizo
  hwmon: (fam15h_power) Add max compute unit accumulated power
  x86, amd: add accessor for number of cores per compute unit
  hwmon: (fam15h_power) Add compute unit accumulated power
  hwmon: (fam15h_power) Add ptsc counter value for accumulated power
  hwmon: (fam15h_power) Introduce a cpu accumulated power reporting
algorithm
  hwmon: (fam15h_power) Add documentation for previous TDP reporting
  hwmon: (fam15h_power) Add documentation for accumulated power
algorithm
  MAINTAINERS: change the maintainer of fam15h_power driver

 CREDITS  |   8 ++
 Documentation/hwmon/fam15h_power |  56 +++-
 MAINTAINERS  |   4 +-
 arch/x86/include/asm/msr-index.h |   1 +
 arch/x86/include/asm/processor.h |   1 +
 arch/x86/kernel/cpu/amd.c|  19 ++-
 drivers/hwmon/fam15h_power.c | 274 +++
 7 files changed, 335 insertions(+), 28 deletions(-)

-- 
1.9.1

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

Re: [RFC PATCH] qspinlock: Improve performance by reducing load instruction rollback

[Ling Ma]

2015-10-19 17:33 GMT+08:00 Peter Zijlstra :
> On Mon, Oct 19, 2015 at 10:27:22AM +0800, ling.ma.prog...@gmail.com wrote:
>> From: Ma Ling 
>>
>> All load instructions can run speculatively but they have to follow
>> memory order rule in multiple cores as below:
>> _x = _y = 0
>>
>> Processor 0   Processor 1
>>
>> mov r1, [ _y]  //M1   mov [ _x], 1  //M3
>> mov r2, [ _x]  //M2   mov [ _y], 1  //M4
>>
>> If r1 = 1, r2 must be 1
>>
>> In order to guarantee above rule, although Processor 0 execute
>> M1 and M2 instruction out of order, they are kept in ROB,
>> when load buffer for _x in Processor 0 received the update
>> message from Processor 1, Processor 0 need to roll back
>> from M2 instruction, which will flush the whole pipeline,
>> the latency is over the penalty from branch prediction miss.
>>
>> In this patch we use lock cmpxchg instruction to force load
>> instructions to be serialization, the destination operand
>> receives a write cycle without regard to the result of
>> the comparison, which can help us to reduce the penalty
>> from load instruction roll back.
>>
>> Our experiment indicates the performance can be improved by 10%~15%
>> for 2 and 3 threads cases, the conflicts from lock cache line
>> spend them most of the time.
>
> On what hardware? Also, you forgot to Cc Waiman, who is a prime author
> of this code. Excessive quoting for his benefit.
>
>> Signed-off-by: Ma Ling 
>> ---
>>  kernel/locking/qspinlock.c |   43 
>> ++-
>>  1 files changed, 18 insertions(+), 25 deletions(-)
>>
>> diff --git a/kernel/locking/qspinlock.c b/kernel/locking/qspinlock.c
>> index 87e9ce6..16421f2 100644
>> --- a/kernel/locking/qspinlock.c
>> +++ b/kernel/locking/qspinlock.c
>> @@ -332,25 +332,14 @@ void queued_spin_lock_slowpath(struct qspinlock *lock, 
>> u32 val)
>>   if (new == _Q_LOCKED_VAL)
>>   return;
>>
>> - /*
>> -  * we're pending, wait for the owner to go away.
>> -  *
>> -  * *,1,1 -> *,1,0
>> + /* we're waiting, and get lock owner
>
> That's incorrect coding style
Ok, I will fix, thx.
>
>>*
>> -  * this wait loop must be a load-acquire such that we match the
>> -  * store-release that clears the locked bit and create lock
>> -  * sequentiality; this is because not all clear_pending_set_locked()
>> -  * implementations imply full barriers.
>> +  * *,1,* -> *,0,1
>>*/
>> - while ((val = smp_load_acquire(>val.counter)) & _Q_LOCKED_MASK)
>> + while (cmpxchg(&((struct __qspinlock *)lock)->locked_pending,
>> + _Q_PENDING_VAL, _Q_LOCKED_VAL) != _Q_PENDING_VAL)
>
> That's both horrible coding style and painful, we should not spin-wait
> with a cmpxchg instruction like that.
Ok I will fix
>
>>   cpu_relax();
>> -
>> - /*
>> -  * take ownership and clear the pending bit.
>> -  *
>> -  * *,1,0 -> *,0,1
>> -  */
>> - clear_pending_set_locked(lock);
>> +
>>   return;
>>
>>   /*
>> @@ -399,17 +388,21 @@ queue:
>>* we're at the head of the waitqueue, wait for the owner & pending to
>>* go away.
>>*
>> -  * *,x,y -> *,0,0
>> -  *
>> -  * this wait loop must use a load-acquire such that we match the
>> -  * store-release that clears the locked bit and create lock
>> -  * sequentiality; this is because the set_locked() function below
>> -  * does not imply a full barrier.
>> -  *
>> +  * *,x,y -> *,0,1
>>*/
>>   pv_wait_head(lock, node);
>> - while ((val = smp_load_acquire(>val.counter)) & 
>> _Q_LOCKED_PENDING_MASK)
>> + next = READ_ONCE(node->next);
>> + while (cmpxchg(&((struct __qspinlock *)lock)->locked_pending, 0,
>> + _Q_LOCKED_VAL) != 0) {
>
> idem
>
>> + next = READ_ONCE(node->next);
>>   cpu_relax();
>> + }
>> +
>> + if (next)
>> + goto next_node;
>> +
>> + val = smp_load_acquire(>val.counter);
>> + tail = tail | _Q_LOCKED_VAL;
>>
>>   /*
>>* claim the lock:
>> @@ -423,7 +416,6 @@ queue:
>>*/
>>   for (;;) {
>>   if (val != tail) {
>> - set_locked(lock);
>>   break;
>>   }
>>   old = atomic_cmpxchg(>val, val, _Q_LOCKED_VAL);
>> @@ -439,6 +431,7 @@ queue:
>>   while (!(next = READ_ONCE(node->next)))
>>   cpu_relax();
>>
>> +next_node:
>>   arch_mcs_spin_unlock_contended(>locked);
>>   pv_kick_node(lock, next);
>>
>> --
>> 1.7.1
>>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH] qspinlock: Improve performance by reducing load instruction rollback

[Ling Ma]

>
> So it would be nice to create a new user-space spinlock testing facility, via 
> a
> new 'perf bench spinlock' feature or so. That way others can test and validate
> your results on different hardware as well.
>
Attached the spinlock test module . Queued spinlock will run very
slowly in user space
because process switch context, it is OK for  spinlock-test
implementation with kernel module ?

Thanks
Ling


spinlock.tar.bz2
Description: BZip2 compressed data

[GIT PULL] Keys bugfixes

[James Morris]

Please pull these key susbystem fixes for 4.3, per the message from David 
Howells:

"Here are two patches, the first of which at least should go upstream
immediately:

 (1) Prevent a user-triggerable crash in the keyrings destructor when a
 negatively instantiated keyring is garbage collected.  I have also 
 seen this triggered for user type keys.

 (2) Prevent the user from using requesting that a keyring be created and
 instantiated through an upcall.  Doing so is probably safe since the 
 keyring type ignores the arguments to its instantiation function - 
 but we probably shouldn't let keyrings be created in this manner."

---

The following changes since commit 1099f86044111e9a7807f09523e42d4c9d0fb781:

  Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net (2015-10-19 
09:55:40 -0700)

are available in the git repository at:

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

David Howells (2):
  KEYS: Fix crash when attempt to garbage collect an uninstantiated keyring
  KEYS: Don't permit request_key() to construct a new keyring

 security/keys/gc.c  |6 --
 security/keys/request_key.c |3 +++
 2 files changed, 7 insertions(+), 2 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 0/2] *** wm8962 regmap related fix ***

[Jiada Wang]

This patch set aims to fix issues in wm8962 codec driver related to regmap,
currently any attempt to read from ALC Coefficient register will fail
when wm8962 is in suspend mode. As ALC2 register is volatile register,
it can't be read when cache_only flag is set.

Another issue is, if wm8962's regulator is set to 'regulator-always-on'
mode, then after wm8962 is resumed from suspend, wm8962 codec is reset,
but cache_dirty flag isn't set, this cause difference between actual wm8962
HW and regmap cache.


Changeset:
--
v1 -> v2
* removed comment before regcache_mark_dirty 

Jiada Wang (2):
  ASoC: WM8962: mark cache_dirty flag after software reset in pm_resume
  ASoC: Codec: wm8962: declare ALC Coefficients as 4 separate registers

 sound/soc/codecs/wm8962.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

-- 
2.4.5

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

[PATCH 2/2] ASoC: Codec: wm8962: declare ALC Coefficients as 4 separate registers

[Jiada Wang]

As ALC2 register is volatile, declare it as one of ALC Coefficients
register together with other non-volatile registers will cause issue,
in case wm8962 has enter suspend mode, and cache_only flag is set,
any attempt to read from ALC2 will fail.

Instead of declaring one ALC Coefficients register which contains
ALC1 ~ ALC3 and Noise Gate, this patch declares 4 separate registers,
so that regmap can handle these registers differently based on their
classification.

Signed-off-by: Jiada Wang 
---
 sound/soc/codecs/wm8962.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/sound/soc/codecs/wm8962.c b/sound/soc/codecs/wm8962.c
index a3d7778..157530c 100644
--- a/sound/soc/codecs/wm8962.c
+++ b/sound/soc/codecs/wm8962.c
@@ -1782,8 +1782,11 @@ SND_SOC_BYTES("HD Bass Coefficients", 
WM8962_HDBASS_AI_1, 30),
 
 SOC_DOUBLE("ALC Switch", WM8962_ALC1, WM8962_ALCL_ENA_SHIFT,
WM8962_ALCR_ENA_SHIFT, 1, 0),
-SND_SOC_BYTES_MASK("ALC Coefficients", WM8962_ALC1, 4,
+SND_SOC_BYTES_MASK("ALC1", WM8962_ALC1, 1,
WM8962_ALCL_ENA_MASK | WM8962_ALCR_ENA_MASK),
+SND_SOC_BYTES("ALC2", WM8962_ALC2, 1),
+SND_SOC_BYTES("ALC3", WM8962_ALC3, 1),
+SND_SOC_BYTES("Noise Gate", WM8962_NOISE_GATE, 1),
 };
 
 static const struct snd_kcontrol_new wm8962_spk_mono_controls[] = {
-- 
2.4.5

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

[PATCH 1/2] ASoC: WM8962: mark cache_dirty flag after software reset in pm_resume

[Jiada Wang]

By doing software reset of wm8962 in pm_resume, all registers which
have already been set will be reset to default value without regmap
interface be involved, thus driver need to mark cache_dirty flag,
to let regcache can be updated by regcache_sync().

Signed-off-by: Jiada Wang 
---
 sound/soc/codecs/wm8962.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/sound/soc/codecs/wm8962.c b/sound/soc/codecs/wm8962.c
index 293e47a..a3d7778 100644
--- a/sound/soc/codecs/wm8962.c
+++ b/sound/soc/codecs/wm8962.c
@@ -3805,6 +3805,8 @@ static int wm8962_runtime_resume(struct device *dev)
 
wm8962_reset(wm8962);
 
+   regcache_mark_dirty(wm8962->regmap);
+
/* SYSCLK defaults to on; make sure it is off so we can safely
 * write to registers if the device is declocked.
 */
-- 
2.4.5

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

[PATCH v2 07/10] hwmon: (fam15h_power) Introduce a cpu accumulated power reporting algorithm

[Huang Rui]

This patch introduces an algorithm that computes the average power by
reading a delta value of “core power accumulator” register during
measurement interval, and then dividing delta value by the length of
the time interval.

User is able to use power1_average entry to measure the processor power
consumption and power1_average_interval entry to set the interval.

A simple example:

ray@hr-ub:~/tip$ sensors
fam15h_power-pci-00c4
Adapter: PCI adapter
power1:   23.73 mW (avg = 634.63 mW, interval =   0.01 s)
   (crit =  15.00 W)

...

The result is current average processor power consumption in 10
millisecond. The unit of the result is uWatt.

Suggested-by: Guenter Roeck 
Signed-off-by: Huang Rui 
Cc: Borislav Petkov 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
---
 drivers/hwmon/fam15h_power.c | 120 +++
 1 file changed, 120 insertions(+)

diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
index 6321f73..a5a539e 100644
--- a/drivers/hwmon/fam15h_power.c
+++ b/drivers/hwmon/fam15h_power.c
@@ -26,6 +26,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
 #include 
 
@@ -64,6 +67,10 @@ struct fam15h_power_data {
u64 cu_acc_power[MAX_CUS];
/* performance timestamp counter */
u64 cpu_sw_pwr_ptsc[MAX_CUS];
+   /* online/offline status of current compute unit */
+   int cu_on[MAX_CUS];
+   unsigned long power_period;
+   struct mutex acc_pwr_mutex;
 };
 
 static ssize_t show_power(struct device *dev,
@@ -132,11 +139,15 @@ static void do_read_registers_on_cu(void *_data)
cores_per_cu = amd_get_cores_per_cu();
cu = cpu / cores_per_cu;
 
+   mutex_lock(>acc_pwr_mutex);
WARN_ON(rdmsrl_safe(MSR_F15H_CU_PWR_ACCUMULATOR,
>cu_acc_power[cu]));
 
WARN_ON(rdmsrl_safe(MSR_F15H_PTSC,
>cpu_sw_pwr_ptsc[cu]));
+
+   data->cu_on[cu] = 1;
+   mutex_unlock(>acc_pwr_mutex);
 }
 
 static int read_registers(struct fam15h_power_data *data)
@@ -148,6 +159,10 @@ static int read_registers(struct fam15h_power_data *data)
cores_per_cu = amd_get_cores_per_cu();
cu_num = boot_cpu_data.x86_max_cores / cores_per_cu;
 
+   mutex_lock(>acc_pwr_mutex);
+   memset(data->cu_on, 0, sizeof(int) * MAX_CUS);
+   mutex_unlock(>acc_pwr_mutex);
+
WARN_ON_ONCE(cu_num > MAX_CUS);
 
ret = zalloc_cpumask_var(, GFP_KERNEL);
@@ -184,18 +199,113 @@ static int read_registers(struct fam15h_power_data *data)
return 0;
 }
 
+static ssize_t acc_show_power(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+   struct fam15h_power_data *data = dev_get_drvdata(dev);
+   u64 prev_cu_acc_power[MAX_CUS], prev_ptsc[MAX_CUS],
+   jdelta[MAX_CUS];
+   u64 tdelta, avg_acc;
+   int cu, cu_num, cores_per_cu, ret;
+   signed long leftover;
+
+   cores_per_cu = amd_get_cores_per_cu();
+   cu_num = boot_cpu_data.x86_max_cores / cores_per_cu;
+
+   ret = read_registers(data);
+   if (ret)
+   return 0;
+
+   cu = 0;
+   while(cu++ < cu_num) {
+   prev_cu_acc_power[cu] = data->cu_acc_power[cu];
+   prev_ptsc[cu] = data->cpu_sw_pwr_ptsc[cu];
+   }
+
+   leftover = schedule_timeout_interruptible(
+   msecs_to_jiffies(data->power_period)
+  );
+   if (leftover)
+   return 0;
+
+   ret = read_registers(data);
+   if (ret)
+   return 0;
+
+   for (cu = 0, avg_acc = 0; cu < cu_num; cu++) {
+   /* check if current compute unit is online */
+   if (data->cu_on[cu] == 0)
+   continue;
+
+   if (data->cu_acc_power[cu] < prev_cu_acc_power[cu]) {
+   jdelta[cu] = data->max_cu_acc_power + 
data->cu_acc_power[cu];
+   jdelta[cu] -= prev_cu_acc_power[cu];
+   } else {
+   jdelta[cu] = data->cu_acc_power[cu] - 
prev_cu_acc_power[cu];
+   }
+   tdelta = data->cpu_sw_pwr_ptsc[cu] - prev_ptsc[cu];
+   jdelta[cu] *= data->cpu_pwr_sample_ratio * 1000;
+   do_div(jdelta[cu], tdelta);
+
+   /* the unit is microWatt */
+   avg_acc += jdelta[cu];
+   }
+
+   return sprintf(buf, "%llu\n", (unsigned long long)avg_acc);
+}
+static DEVICE_ATTR(power1_average, S_IRUGO, acc_show_power, NULL);
+
+
+static ssize_t acc_show_power_period(struct device *dev,
+struct device_attribute *attr,
+char *buf)
+{
+   struct fam15h_power_data *data = dev_get_drvdata(dev);
+
+   return sprintf(buf, "%lu\n", data->power_period);
+}
+
+static ssize_t acc_set_power_period(struct device *dev,
+  

[PATCH v2 10/10] MAINTAINERS: change the maintainer of fam15h_power driver

[Huang Rui]

Andreas Herrmann won't take the maintainer of fam15h_power driver. I
will take it and appreciate him for the great contributions on this
driver.

Signed-off-by: Huang Rui 
Acked-by: Andreas Herrmann 
Cc: Borislav Petkov 
Cc: Aravind Gopalakrishnan 
---
 CREDITS | 8 
 MAINTAINERS | 4 ++--
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/CREDITS b/CREDITS
index 8207cc6..30bdce8 100644
--- a/CREDITS
+++ b/CREDITS
@@ -1507,6 +1507,14 @@ S: 312/107 Canberra Avenue
 S: Griffith, ACT 2603 
 S: Australia
 
+N: Andreas Herrmann
+E: herrmann.der.u...@gmail.com
+E: herrmann.der.u...@googlemail.com
+D: Key developer of x86/AMD64
+D: Author of AMD family 15h processor power monintoring driver
+D: Maintainer of AMD Athlon 64 and Opteron processor frequency driver
+S: Germany
+
 N: Sebastian Hetze
 E: s...@lunetix.de
 D: German Linux Documentation,
diff --git a/MAINTAINERS b/MAINTAINERS
index 7ba7ab7..639a957 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -608,9 +608,9 @@ F:  drivers/crypto/ccp/
 F: include/linux/ccp.h
 
 AMD FAM15H PROCESSOR POWER MONITORING DRIVER
-M: Andreas Herrmann 
+M: Huang Rui 
 L: lm-sens...@lm-sensors.org
-S: Maintained
+S: Supported
 F: Documentation/hwmon/fam15h_power
 F: drivers/hwmon/fam15h_power.c
 
-- 
1.9.1

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

[PATCH v2 09/10] hwmon: (fam15h_power) Add documentation for accumulated power algorithm

[Huang Rui]

This patch adds the description to explain the accumulated power
algorithm.

Signed-off-by: Huang Rui 
Cc: Borislav Petkov 
Cc: Guenter Roeck 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
---
 Documentation/hwmon/fam15h_power | 46 
 1 file changed, 46 insertions(+)

diff --git a/Documentation/hwmon/fam15h_power b/Documentation/hwmon/fam15h_power
index 42bf04e..74cfbbf 100644
--- a/Documentation/hwmon/fam15h_power
+++ b/Documentation/hwmon/fam15h_power
@@ -45,3 +45,49 @@ This driver provides ProcessorPwrWatts and CurrPwrWatts:
 On multi-node processors the calculated value is for the entire
 package and not for a single node. Thus the driver creates sysfs
 attributes only for internal node0 of a multi-node processor.
+
+2) Accumulated Power Mechanism
+
+This driver also introduces an algorithm that should be used to
+calculate the average power consumed by a processor during a
+measurement interval Tm. The feature of accumulated power mechanism is
+indicated by CPUID Fn8000_0007_EDX[12].
+
+* Tsample: compute unit power accumulator sample period
+* Tref: the PTSC counter period
+* PTSC: performance timestamp counter
+* N: the ratio of compute unit power accumulator sample period to the
+  PTSC period
+* Jmax: max compute unit accumulated power which is indicated by
+  MaxCpuSwPwrAcc MSR C001007b
+* Jx/Jy: compute unit accumulated power which is indicated by
+  CpuSwPwrAcc MSR C001007a
+* Tx/Ty: the value of performance timestamp counter which is indicated
+  by CU_PTSC MSR C0010280
+* PwrCPUave: CPU average power
+
+i. Determine the ratio of Tsample to Tref by executing CPUID Fn8000_0007.
+   N = value of CPUID Fn8000_0007_ECX[CpuPwrSampleTimeRatio[15:0]].
+
+ii. Read the full range of the cumulative energy value from the new
+MSR MaxCpuSwPwrAcc.
+   Jmax = value returned.
+iii. At time x, SW reads CpuSwPwrAcc MSR and samples the PTSC.
+   Jx = value read from CpuSwPwrAcc and Tx = value read from
+PTSC.
+
+iv. At time y, SW reads CpuSwPwrAcc MSR and samples the PTSC.
+   Jy = value read from CpuSwPwrAcc and Ty = value read from
+PTSC.
+
+v. Calculate the average power consumption for a compute unit over
+time period (y-x). Unit of result is uWatt.
+   if (Jy < Jx) // Rollover has occurred
+   Jdelta = (Jy + Jmax) - Jx
+   else
+   Jdelta = Jy - Jx
+   PwrCPUave = N * Jdelta * 1000 / (Ty - Tx)
+
+This driver provides PwrCPUave and interval(default is 10 millisecond):
+* power1_average (PwrCPUave)
+* power1_average_interval (Interval)
-- 
1.9.1

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

[PATCH v2 01/10] hwmon: (fam15h_power) Refactor attributes for dynamically added

[Huang Rui]

Attributes depend on the CPU model the driver gets loaded on.
Therefore, add those attributes dynamically at init time. This is more
flexible to control the different attributes on different platforms.

Suggestedy-by: Borislav Petkov 
Signed-off-by: Huang Rui 
Cc: Guenter Roeck 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
---
 drivers/hwmon/fam15h_power.c | 70 
 1 file changed, 45 insertions(+), 25 deletions(-)

diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
index e80ee23..41d022e 100644
--- a/drivers/hwmon/fam15h_power.c
+++ b/drivers/hwmon/fam15h_power.c
@@ -41,12 +41,17 @@ MODULE_LICENSE("GPL");
 #define REG_TDP_RUNNING_AVERAGE0xe0
 #define REG_TDP_LIMIT3 0xe8
 
+#define FAM15H_MIN_NUM_ATTRS   2
+#define FAM15H_NUM_GROUPS  2
+
 struct fam15h_power_data {
struct pci_dev *pdev;
unsigned int tdp_to_watts;
unsigned int base_tdp;
unsigned int processor_pwr_watts;
unsigned int cpu_pwr_sample_ratio;
+   const struct attribute_group *fam15h_power_groups[FAM15H_NUM_GROUPS];
+   struct attribute_group fam15h_power_group;
 };
 
 static ssize_t show_power(struct device *dev,
@@ -105,29 +110,31 @@ static ssize_t show_power_crit(struct device *dev,
 }
 static DEVICE_ATTR(power1_crit, S_IRUGO, show_power_crit, NULL);
 
-static umode_t fam15h_power_is_visible(struct kobject *kobj,
-  struct attribute *attr,
-  int index)
+static int fam15h_power_init_attrs(struct pci_dev *pdev,
+  struct fam15h_power_data *data)
 {
-   /* power1_input is only reported for Fam15h, Models 00h-0fh */
-   if (attr == _attr_power1_input.attr &&
-  (boot_cpu_data.x86 != 0x15 || boot_cpu_data.x86_model > 0xf))
-   return 0;
+   int n = FAM15H_MIN_NUM_ATTRS;
+   struct attribute **fam15h_power_attrs;
 
-   return attr->mode;
-}
+   if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model <= 0xf)
+   n += 1;
 
-static struct attribute *fam15h_power_attrs[] = {
-   _attr_power1_input.attr,
-   _attr_power1_crit.attr,
-   NULL
-};
+   fam15h_power_attrs = devm_kcalloc(>dev, n,
+ sizeof(*fam15h_power_attrs),
+ GFP_KERNEL);
 
-static const struct attribute_group fam15h_power_group = {
-   .attrs = fam15h_power_attrs,
-   .is_visible = fam15h_power_is_visible,
-};
-__ATTRIBUTE_GROUPS(fam15h_power);
+   if (!fam15h_power_attrs)
+   return -ENOMEM;
+
+   n = 0;
+   fam15h_power_attrs[n++] = _attr_power1_crit.attr;
+   if (boot_cpu_data.x86 == 0x15 && boot_cpu_data.x86_model <= 0xf)
+   fam15h_power_attrs[n++] = _attr_power1_input.attr;
+
+   data->fam15h_power_group.attrs = fam15h_power_attrs;
+
+   return 0;
+}
 
 static bool should_load_on_this_node(struct pci_dev *f4)
 {
@@ -186,11 +193,12 @@ static int fam15h_power_resume(struct pci_dev *pdev)
 #define fam15h_power_resume NULL
 #endif
 
-static void fam15h_power_init_data(struct pci_dev *f4,
-struct fam15h_power_data *data)
+static int fam15h_power_init_data(struct pci_dev *f4,
+ struct fam15h_power_data *data)
 {
u32 val, eax, ebx, ecx, edx;
u64 tmp;
+   int ret;
 
pci_read_config_dword(f4, REG_PROCESSOR_TDP, );
data->base_tdp = val >> 16;
@@ -211,11 +219,15 @@ static void fam15h_power_init_data(struct pci_dev *f4,
/* convert to microWatt */
data->processor_pwr_watts = (tmp * 15625) >> 10;
 
+   ret = fam15h_power_init_attrs(f4, data);
+   if (ret)
+   return ret;
+
cpuid(0x8007, , , , );
 
/* CPUID Fn8000_0007:EDX[12] indicates to support accumulated power */
if (!(edx & BIT(12)))
-   return;
+   return 0;
 
/*
 * determine the ratio of the compute unit power accumulator
@@ -223,14 +235,17 @@ static void fam15h_power_init_data(struct pci_dev *f4,
 * Fn8000_0007:ECX
 */
data->cpu_pwr_sample_ratio = ecx;
+
+   return 0;
 }
 
 static int fam15h_power_probe(struct pci_dev *pdev,
-   const struct pci_device_id *id)
+ const struct pci_device_id *id)
 {
struct fam15h_power_data *data;
struct device *dev = >dev;
struct device *hwmon_dev;
+   int ret;
 
/*
 * though we ignore every other northbridge, we still have to
@@ -246,12 +261,17 @@ static int fam15h_power_probe(struct pci_dev *pdev,
if (!data)
return -ENOMEM;
 
-   fam15h_power_init_data(pdev, data);
+   ret = fam15h_power_init_data(pdev, data);
+   if (ret)
+   return ret;
+

[PATCH v2 04/10] x86, amd: add accessor for number of cores per compute unit

[Huang Rui]

Add an accessor function amd_get_cores_per_cu() which returns the
number of cores per compute unit. In multiple CPUs, they always have
the same number of cores per compute unit.

In a subsequent patch, we will use this function in fam15h_power
driver.

Signed-off-by: Huang Rui 
Cc: Borislav Petkov 
Cc: Guenter Roeck 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
---
 arch/x86/include/asm/processor.h |  1 +
 arch/x86/kernel/cpu/amd.c| 19 +--
 2 files changed, 18 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 19577dd..831ad682 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -810,6 +810,7 @@ static inline int mpx_disable_management(void)
 
 extern u16 amd_get_nb_id(int cpu);
 extern u32 amd_get_nodes_per_socket(void);
+extern u32 amd_get_cores_per_cu(void);
 
 static inline uint32_t hypervisor_cpuid_base(const char *sig, uint32_t leaves)
 {
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 4a70fc6..a914b1b 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -27,6 +27,9 @@
  */
 static u32 nodes_per_socket = 1;
 
+/* cores_per_cu: stores the number of cores per compute unit */
+static u32 cores_per_cu = 1;
+
 static inline int rdmsrl_amd_safe(unsigned msr, unsigned long long *p)
 {
u32 gprs[8] = { 0 };
@@ -299,7 +302,6 @@ static int nearby_node(int apicid)
 #ifdef CONFIG_SMP
 static void amd_get_topology(struct cpuinfo_x86 *c)
 {
-   u32 cores_per_cu = 1;
u8 node_id;
int cpu = smp_processor_id();
 
@@ -314,7 +316,6 @@ static void amd_get_topology(struct cpuinfo_x86 *c)
/* get compute unit information */
smp_num_siblings = ((ebx >> 8) & 3) + 1;
c->compute_unit_id = ebx & 0xff;
-   cores_per_cu += ((ebx >> 8) & 3);
} else if (cpu_has(c, X86_FEATURE_NODEID_MSR)) {
u64 value;
 
@@ -380,6 +381,13 @@ u32 amd_get_nodes_per_socket(void)
 }
 EXPORT_SYMBOL_GPL(amd_get_nodes_per_socket);
 
+/* this function returns the number of cores per compute unit */
+u32 amd_get_cores_per_cu(void)
+{
+   return cores_per_cu;
+}
+EXPORT_SYMBOL_GPL(amd_get_cores_per_cu);
+
 static void srat_detect_node(struct cpuinfo_x86 *c)
 {
 #ifdef CONFIG_NUMA
@@ -510,6 +518,13 @@ static void bsp_init_amd(struct cpuinfo_x86 *c)
 
if (cpu_has(c, X86_FEATURE_MWAITX))
use_mwaitx_delay();
+
+   if (cpu_has_topoext) {
+   u32 cpuid;
+
+   cpuid = cpuid_ebx(0x801e);
+   cores_per_cu += ((cpuid >> 8) & 3);
+   }
 }
 
 static void early_init_amd(struct cpuinfo_x86 *c)
-- 
1.9.1

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

[PATCH v2 06/10] hwmon: (fam15h_power) Add ptsc counter value for accumulated power

[Huang Rui]

PTSC is the performance timestamp counter value in a cpu core and the
cores in one compute unit have the fixed frequency. So it picks up the
performance timestamp counter value of the first core per compute unit
to measure the interval for average power per compute unit.

Signed-off-by: Huang Rui 
Cc: Borislav Petkov 
Cc: Guenter Roeck 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
---
 arch/x86/include/asm/msr-index.h | 1 +
 drivers/hwmon/fam15h_power.c | 5 +
 2 files changed, 6 insertions(+)

diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index c1c0a1c..3686eaa 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -313,6 +313,7 @@
 #define MSR_F15H_PERF_CTR  0xc0010201
 #define MSR_F15H_NB_PERF_CTL   0xc0010240
 #define MSR_F15H_NB_PERF_CTR   0xc0010241
+#define MSR_F15H_PTSC  0xc0010280
 
 /* Fam 10h MSRs */
 #define MSR_FAM10H_MMIO_CONF_BASE  0xc0010058
diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
index 88e4f3e..6321f73 100644
--- a/drivers/hwmon/fam15h_power.c
+++ b/drivers/hwmon/fam15h_power.c
@@ -62,6 +62,8 @@ struct fam15h_power_data {
u64 max_cu_acc_power;
/* accumulated power of the compute units */
u64 cu_acc_power[MAX_CUS];
+   /* performance timestamp counter */
+   u64 cpu_sw_pwr_ptsc[MAX_CUS];
 };
 
 static ssize_t show_power(struct device *dev,
@@ -132,6 +134,9 @@ static void do_read_registers_on_cu(void *_data)
 
WARN_ON(rdmsrl_safe(MSR_F15H_CU_PWR_ACCUMULATOR,
>cu_acc_power[cu]));
+
+   WARN_ON(rdmsrl_safe(MSR_F15H_PTSC,
+   >cpu_sw_pwr_ptsc[cu]));
 }
 
 static int read_registers(struct fam15h_power_data *data)
-- 
1.9.1

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

[PATCH v2 05/10] hwmon: (fam15h_power) Add compute unit accumulated power

[Huang Rui]

This patch adds a member in fam15h_power_data which specifies the
compute unit accumulated power. It adds do_read_registers_on_cu to do
all the read to all MSRs and run it on one of the online cores on each
compute unit with smp_call_function_many(). This behavior can decrease
IPI numbers.

Suggested-by: Borislav Petkov 
Signed-off-by: Huang Rui 
Cc: Guenter Roeck 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
---
 drivers/hwmon/fam15h_power.c | 68 +++-
 1 file changed, 67 insertions(+), 1 deletion(-)

diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
index e2bfab5..88e4f3e 100644
--- a/drivers/hwmon/fam15h_power.c
+++ b/drivers/hwmon/fam15h_power.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -44,7 +45,9 @@ MODULE_LICENSE("GPL");
 
 #define FAM15H_MIN_NUM_ATTRS   2
 #define FAM15H_NUM_GROUPS  2
+#define MAX_CUS8
 
+#define MSR_F15H_CU_PWR_ACCUMULATOR0xc001007a
 #define MSR_F15H_CU_MAX_PWR_ACCUMULATOR0xc001007b
 
 struct fam15h_power_data {
@@ -57,6 +60,8 @@ struct fam15h_power_data {
struct attribute_group fam15h_power_group;
/* maximum accumulated power of a compute unit */
u64 max_cu_acc_power;
+   /* accumulated power of the compute units */
+   u64 cu_acc_power[MAX_CUS];
 };
 
 static ssize_t show_power(struct device *dev,
@@ -115,6 +120,65 @@ static ssize_t show_power_crit(struct device *dev,
 }
 static DEVICE_ATTR(power1_crit, S_IRUGO, show_power_crit, NULL);
 
+static void do_read_registers_on_cu(void *_data)
+{
+   struct fam15h_power_data *data = _data;
+   int cpu, cu, cores_per_cu;
+
+   cpu = smp_processor_id();
+
+   cores_per_cu = amd_get_cores_per_cu();
+   cu = cpu / cores_per_cu;
+
+   WARN_ON(rdmsrl_safe(MSR_F15H_CU_PWR_ACCUMULATOR,
+   >cu_acc_power[cu]));
+}
+
+static int read_registers(struct fam15h_power_data *data)
+{
+   int this_cpu, ret;
+   int cu_num, cores_per_cu, cpu, cu;
+   cpumask_var_t mask;
+
+   cores_per_cu = amd_get_cores_per_cu();
+   cu_num = boot_cpu_data.x86_max_cores / cores_per_cu;
+
+   WARN_ON_ONCE(cu_num > MAX_CUS);
+
+   ret = zalloc_cpumask_var(, GFP_KERNEL);
+   if (!ret)
+   return -ENOMEM;
+
+   this_cpu = get_cpu();
+
+   /*
+* Choose the first online core of each compute unit, and then
+* read their MSR value of power and ptsc in one time of IPI,
+* because the MSR value of cpu core represent the compute
+* unit's. This behavior can decrease IPI numbers between the
+* cores.
+*/
+   cpu = cpumask_first(cpu_online_mask);
+   cu = cpu / cores_per_cu;
+   while (cpu < boot_cpu_data.x86_max_cores) {
+   if (cu <= cpu / cores_per_cu) {
+   cu = cpu / cores_per_cu + 1;
+   cpumask_set_cpu(cpu, mask);
+   }
+   cpu = cpumask_next(cu * cores_per_cu - 1, cpu_online_mask);
+   }
+
+   if (cpumask_test_cpu(this_cpu, mask))
+   do_read_registers_on_cu(data);
+
+   smp_call_function_many(mask, do_read_registers_on_cu, data, true);
+   put_cpu();
+
+   free_cpumask_var(mask);
+
+   return 0;
+}
+
 static int fam15h_power_init_attrs(struct pci_dev *pdev,
   struct fam15h_power_data *data)
 {
@@ -253,7 +317,9 @@ static int fam15h_power_init_data(struct pci_dev *f4,
 
data->max_cu_acc_power = tmp;
 
-   return 0;
+   ret = read_registers(data);
+
+   return ret;
 }
 
 static int fam15h_power_probe(struct pci_dev *pdev,
-- 
1.9.1

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

[PATCH v2 03/10] hwmon: (fam15h_power) Add max compute unit accumulated power

[Huang Rui]

This patch adds a member in fam15h_power_data which specifies the
maximum accumulated power in a compute unit.

Signed-off-by: Huang Rui 
Cc: Borislav Petkov 
Cc: Guenter Roeck 
Cc: Peter Zijlstra 
Cc: Ingo Molnar 
---
 drivers/hwmon/fam15h_power.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/hwmon/fam15h_power.c b/drivers/hwmon/fam15h_power.c
index a090adf..e2bfab5 100644
--- a/drivers/hwmon/fam15h_power.c
+++ b/drivers/hwmon/fam15h_power.c
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 MODULE_DESCRIPTION("AMD Family 15h CPU processor power monitor");
 MODULE_AUTHOR("Andreas Herrmann ");
@@ -44,6 +45,8 @@ MODULE_LICENSE("GPL");
 #define FAM15H_MIN_NUM_ATTRS   2
 #define FAM15H_NUM_GROUPS  2
 
+#define MSR_F15H_CU_MAX_PWR_ACCUMULATOR0xc001007b
+
 struct fam15h_power_data {
struct pci_dev *pdev;
unsigned int tdp_to_watts;
@@ -52,6 +55,8 @@ struct fam15h_power_data {
unsigned int cpu_pwr_sample_ratio;
const struct attribute_group *fam15h_power_groups[FAM15H_NUM_GROUPS];
struct attribute_group fam15h_power_group;
+   /* maximum accumulated power of a compute unit */
+   u64 max_cu_acc_power;
 };
 
 static ssize_t show_power(struct device *dev,
@@ -241,6 +246,13 @@ static int fam15h_power_init_data(struct pci_dev *f4,
 */
data->cpu_pwr_sample_ratio = ecx;
 
+   if (rdmsrl_safe(MSR_F15H_CU_MAX_PWR_ACCUMULATOR, )) {
+   pr_err("Failed to read max compute unit power accumulator 
MSR\n");
+   return -ENODEV;
+   }
+
+   data->max_cu_acc_power = tmp;
+
return 0;
 }
 
-- 
1.9.1

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

Re: [PATCH] perf build: Add fixdep to .gitignore

[Yunlong Song]

On 2015/10/15 16:51, Yunlong Song wrote:
> Commit 7c422f5572667fef0db38d2046ecce69dcf0afc8 ("tools build: Build fixdep
> helper from perf and basic libs") dynamically creates fixdep during the perf
> building. Add it to .gitignore.
> 
> Signed-off-by: Yunlong Song 
> ---
>  tools/build/.gitignore | 1 +
>  1 file changed, 1 insertion(+)
>  create mode 100644 tools/build/.gitignore
> 
> diff --git a/tools/build/.gitignore b/tools/build/.gitignore
> new file mode 100644
> index 000..a776371
> --- /dev/null
> +++ b/tools/build/.gitignore
> @@ -0,0 +1 @@
> +fixdep
> 

ping...

That fixdep really bothers one a lot every time perf is built:

Untracked files:
  (use "git add ..." to include in what will be committed)

../build/fixdep

-- 
Thanks,
Yunlong Song

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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/1] bpf: control events stored in PERF_EVENT_ARRAY maps trace data output when perf sampling

[xiakaixu]

于 2015/10/20 10:14, Alexei Starovoitov 写道:
> On 10/19/15 3:37 AM, Kaixu Xia wrote:
>> +/* flags for PERF_EVENT_ARRAY maps*/
>> +enum {
>> +BPF_EVENT_CTL_BIT_CUR = 0,
>> +BPF_EVENT_CTL_BIT_ALL = 1,
>> +__NR_BPF_EVENT_CTL_BITS,
>> +};
>> +
>> +#defineBPF_CTL_BIT_FLAG_MASK \
>> +((1ULL << __NR_BPF_EVENT_CTL_BITS) - 1)
>> +#defineBPF_CTL_BIT_DUMP_CUR \
>> +(1ULL << BPF_EVENT_CTL_BIT_CUR)
>> +#defineBPF_CTL_BIT_DUMP_ALL \
>> +(1ULL << BPF_EVENT_CTL_BIT_ALL)
>> +
> 
> the above shouldn't be part of uapi header. It can stay in bpf_trace.c
> Just document these bits next to helper similar to skb_store_bytes()
> 
> The rest looks ok.
> It still needs an ack from Peter for perf_event bits

Thanks for your comments!
This part will be moved to bpf_trace.c in next version.
> 
> 
> .
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] usb: chipidea: udc: clear vbus_active flag in udc_stop

[Jiada Wang]

Currently in udc_stop, if vbus_active flag is true, all USB activities
will be stopped, but vbus_active flag is still left to be true,
this causes issue, when afterwards driver tries to connect gadget
device to host, But due to the uncleared vbus_active, some necessary
setup steps are skipped.

This patch clears vbus_active flag in udc_stop callback.

Signed-off-by: Jiada Wang 
---
 drivers/usb/chipidea/udc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/usb/chipidea/udc.c b/drivers/usb/chipidea/udc.c
index 8223fe7..b9ac228 100644
--- a/drivers/usb/chipidea/udc.c
+++ b/drivers/usb/chipidea/udc.c
@@ -1762,6 +1762,7 @@ static int ci_udc_stop(struct usb_gadget *gadget)
spin_lock_irqsave(>lock, flags);
 
if (ci->vbus_active) {
+   ci->vbus_active = 0;
hw_device_state(ci, 0);
if (ci->platdata->notify_event)
ci->platdata->notify_event(ci,
-- 
2.4.5

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

Re: [PATCH] EDAC: Add AMD Seattle SoC EDAC

[Hanjun Guo]

Hi Brijesh,

On 2015/10/20 3:23, Brijesh Singh wrote:
> Add support for the AMD Seattle SoC EDAC driver.
>
> Signed-off-by: Brijesh Singh 
> ---
>  .../devicetree/bindings/edac/amd-seattle-edac.txt  |  15 +
>  drivers/edac/Kconfig   |   6 +
>  drivers/edac/Makefile  |   1 +
>  drivers/edac/seattle_edac.c| 306 
> +
>  4 files changed, 328 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/edac/amd-seattle-edac.txt
>  create mode 100644 drivers/edac/seattle_edac.c
>
>
[...]
> +config EDAC_SEATTLE
> + tristate "AMD Seattle EDAC"
> + depends on EDAC_MM_EDAC && ARCH_SEATTLE
> + help
> +   Support for error detection and correction on the
> +   AMD Seattle SOC.
>  endif # EDAC
> diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
> index ae3c5f3..9e4f3ef 100644
> --- a/drivers/edac/Makefile
> +++ b/drivers/edac/Makefile
> @@ -68,3 +68,4 @@ obj-$(CONFIG_EDAC_OCTEON_PCI)   += 
> octeon_edac-pci.o
>  obj-$(CONFIG_EDAC_ALTERA_MC) += altera_edac.o
>  obj-$(CONFIG_EDAC_SYNOPSYS)  += synopsys_edac.o
>  obj-$(CONFIG_EDAC_XGENE) += xgene_edac.o
> +obj-$(CONFIG_EDAC_SEATTLE)   += seattle_edac.o
> diff --git a/drivers/edac/seattle_edac.c b/drivers/edac/seattle_edac.c
> new file mode 100644
> index 000..78101aa
> --- /dev/null
> +++ b/drivers/edac/seattle_edac.c
> @@ -0,0 +1,306 @@
> +/*
> + * AMD Seattle EDAC
> + *
> + * Copyright (c) 2015, Advanced Micro Devices
> + * Author: Brijesh Singh 
> + *
> + * The driver polls CPUMERRSR_EL1 and L2MERRSR_EL1 registers to logs the 
> + * non-fatal errors. Whereas the single bit and double bit ECC erros are 
> + * handled by firmware.
> + *
> + * This program is free software; you can redistribute  it and/or modify it
> + * under  the terms of  the GNU General  Public License as published by the
> + * Free Software Foundation;  either version 2 of the  License, or (at your
> + * option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "edac_core.h"
> +
> +#define EDAC_MOD_STR "seattle_edac"
> +
> +#define CPUMERRSR_EL1_INDEX(x)   ((x) & 0x1)
> +#define CPUMERRSR_EL1_BANK(x)(((x) >> 18) & 0x1f)
> +#define CPUMERRSR_EL1_RAMID(x)   (((x) >> 24) & 0x7f)
> +#define CPUMERRSR_EL1_VALID(x)   ((x) & (1 << 31))
> +#define CPUMERRSR_EL1_REPEAT(x)  (((x) >> 32) & 0x7f)
> +#define CPUMERRSR_EL1_OTHER(x)   (((x) >> 40) & 0xff)
> +#define CPUMERRSR_EL1_FATAL(x)   ((x) & (1UL << 63))
> +
> +#define L2MERRSR_EL1_INDEX(x)((x) & 0x1)
> +#define L2MERRSR_EL1_CPUID(x)(((x) >> 18) & 0xf)
> +#define L2MERRSR_EL1_RAMID(x)(((x) >> 24) & 0x7f)
> +#define L2MERRSR_EL1_VALID(x)((x) & (1 << 31))
> +#define L2MERRSR_EL1_REPEAT(x)   (((x) >> 32) & 0xff)
> +#define L2MERRSR_EL1_OTHER(x)(((x) >> 40) & 0xff)
> +#define L2MERRSR_EL1_FATAL(x)((x) & (1UL << 63))
> +
> +struct seattle_edac {
> + struct edac_device_ctl_info *edac_ctl;
> +};
> +
> +static inline u64 read_cpumerrsr_el1(void)
> +{
> + u64 val;
> +
> + asm volatile("mrs %0, s3_1_c15_c2_2" : "=r" (val));
> + return val;
> +}
> +
> +static inline void write_cpumerrsr_el1(u64 val)
> +{
> + asm volatile("msr s3_1_c15_c2_2, %0" :: "r" (val));
> +}
> +
> +static inline u64 read_l2merrsr_el1(void)
> +{
> + u64 val;
> +
> + asm volatile("mrs %0, s3_1_c15_c2_3" : "=r" (val));
> + return val;
> +}
> +
> +static inline void write_l2merrsr_el1(u64 val)
> +{
> + asm volatile("msr s3_1_c15_c2_3, %0" :: "r" (val));
> +}
> +
> +static void check_l2merrsr_el1_error(struct edac_device_ctl_info *edac_ctl)
> +{
> + int fatal;
> + int cpuid;
> + u64 val = read_l2merrsr_el1();
> +
> + if (!L2MERRSR_EL1_VALID(val))
> + return;
> +
> + fatal = L2MERRSR_EL1_FATAL(val);
> + cpuid = L2MERRSR_EL1_CPUID(val);
> + edac_printk(KERN_CRIT, EDAC_MOD_STR,
> + "CPU%d detected %s error on L2 (L2MERRSR=%#llx)!\n",
> + smp_processor_id(), fatal ? "fatal" : "non-fatal", val);
> +
> + switch (L2MERRSR_EL1_RAMID(val)) {
> + case 0x10:
> + edac_printk(KERN_CRIT, EDAC_MOD_STR,
> + "L2 Tag RAM cpu %d way %d\n", cpuid / 2, cpuid % 2);
> + break;
> + case 0x11:
> + edac_printk(KERN_CRIT, EDAC_MOD_STR,
> + "L2 Data RAM cpu %d way %d\n", cpuid / 2, cpuid % 
> 2);
> + break;
> + case 0x12:
> +

Re: [PATCH 2/3] mm/hugetlb: Setup hugetlb_falloc during fallocate hole punch

[Hugh Dickins]

On Mon, 19 Oct 2015, Mike Kravetz wrote:
> On 10/19/2015 04:16 PM, Andrew Morton wrote:
> > On Fri, 16 Oct 2015 15:08:29 -0700 Mike Kravetz  
> > wrote:
> 
> >>mutex_lock(>i_mutex);
> >> +
> >> +  spin_lock(>i_lock);
> >> +  inode->i_private = _falloc;
> >> +  spin_unlock(>i_lock);
> > 
> > Locking around a single atomic assignment is a bit peculiar.  I can
> > kinda see that it kinda protects the logic in hugetlb_fault(), but I
> > would like to hear (in comment form) your description of how this logic
> > works?
> 
> To be honest, this code/scheme was copied from shmem as it addresses
> the same situation there.  I did not notice how strange this looks until
> you pointed it out.  At first glance, the locking does appear to be
> unnecessary.  The fault code initially checks this value outside the
> lock.  However, the fault code (on another CPU) will take the lock
> and access values within the structure.  Without the locking or some other
> type of memory barrier here, there is no guarantee that the structure
> will be initialized before setting i_private.  So, the faulting code
> could see invalid values in the structure.
> 
> Hugh, is that accurate?  You provided the shmem code.

Yes, I think that's accurate; but confess I'm replying now for the
sake of replying in a rare timely fashion, before having spent any
time looking through your hugetlbfs reimplementation of the same.

The peculiar thing in the shmem case, was that the structure being
pointed to is on the kernel stack of the fallocating task (with
i_mutex guaranteeing only one at a time per file could be doing this):
so the faulting end has to be careful that it's not accessing the
stale memory after the fallocator has retreated back up its stack.

And in the shmem case, this "temporary inode extension" also had to
communicate to shmem_writepage(), the swapout end of things.  Which
is not a complication you have with hugetlbfs: perhaps it could be
simpler if just between fallocate and fault, or perhaps not.

Whilst it does all work for tmpfs, it looks as if tmpfs was ahead of
the pack (or trinity was attacking tmpfs before other filesystems),
and the issue of faulting versus holepunching (and DAX) has captured
wider interest recently, with Dave Chinner formulating answers in XFS,
and hoping to set an example for other filesystems.

If that work were further along, and if I had had time to digest any
of what he is doing about it, I would point you in his direction rather
than this; but since this does work for tmpfs, I shouldn't discourage you.

I'll try to take a look through yours in the coming days, but there's
several other patchsets I need to look through too, plus a few more
patches from me, if I can find time to send them in: juggling priorities.

Hugh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 RESEND net-next] net: updates HNS config and documents

[yankejian]

updates the bindings documents and dtsi file according to the review
comments from Rob Herring 

Signed-off-by: yankejian 
Signed-off-by: huangdaode 
---
 Documentation/devicetree/bindings/net/hisilicon-hns-mdio.txt | 2 +-
 arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi | 8 +++-
 2 files changed, 4 insertions(+), 6 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/hisilicon-hns-mdio.txt 
b/Documentation/devicetree/bindings/net/hisilicon-hns-mdio.txt
index 9940aa0..9c23fdf 100644
--- a/Documentation/devicetree/bindings/net/hisilicon-hns-mdio.txt
+++ b/Documentation/devicetree/bindings/net/hisilicon-hns-mdio.txt
@@ -12,7 +12,7 @@ Example:
  mdio@803c {
#address-cells = <1>;
#size-cells = <0>;
-   compatible = "hisilicon,mdio","hisilicon,hns-mdio";
+   compatible = "hisilicon,hns-mdio","hisilicon,mdio";
reg = <0x0 0x803c 0x0 0x1>;
 
ethernet-phy@0 {
diff --git a/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi 
b/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
index 3500586..606dd5a 100644
--- a/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
+++ b/arch/arm64/boot/dts/hisilicon/hip05_hns.dtsi
@@ -13,14 +13,12 @@ soc0: soc@0 {
reg = <0x0 0x803c 0x0 0x1
   0x0 0x8000 0x0 0x1>;
 
-   soc0_phy4: ethernet-phy@4 {
+   soc0_phy0: ethernet-phy@0 {
reg = <0x0>;
-   device_type = "ethernet-phy";
compatible = "ethernet-phy-ieee802.3-c22";
};
-   soc0_phy5: ethernet-phy@5 {
+   soc0_phy1: ethernet-phy@1 {
reg = <0x1>;
-   device_type = "ethernet-phy";
compatible = "ethernet-phy-ieee802.3-c22";
};
};
@@ -37,7 +35,7 @@ soc0: soc@0 {
   0x0 0xc700 0x0 0x6
   >;
 
-   phy-handle = <0 0 0 0 _phy4 _phy5 0 0>;
+   phy-handle = <0 0 0 0 _phy0 _phy1 0 0>;
interrupts = <
/* [14] ge fifo err 8 / xge 6**/
149 0x4 150 0x4 151 0x4 152 0x4
-- 
1.9.1

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

Re: [PATCH 3.4 00/65] 3.4.110-rc1 review

[Guenter Roeck]

On 10/19/2015 05:47 PM, l...@kernel.org wrote:

From: Zefan Li 

This is the start of the stable review cycle for the 3.4.110 release.
There are 65 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.



Build results:
total: 97 pass: 96 fail: 1
Failed builds:
m68k:sun3_defconfig

Qemu test results:
total: 63 pass: 63 fail: 0

Build failure is due to inconsistent kallsyms data when building 
m68k:sun3_defconfig.
From the build log:

Inconsistent kallsyms data
This is a bug - please report about it
Try make KALLSYMS_EXTRA_PASS=1 as a workaround
Makefile:922: recipe for target 'vmlinux' failed

Bisect says that the problem is caused by "vfs: Test for and handle paths
that are unreachable from  their mnt_root", and reverting that patch
fixes the problem. No idea what is going on. Copying Eric and Geert.

Details are available at http://server.roeck-us.net:8010/builders.

Guenter

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

Re: [PATCH V3 2/4] ACPI/scan: Clean up acpi_check_dma

[Bjorn Helgaas]

On Tue, Oct 13, 2015 at 06:53:28PM -0500, Suravee Suthikulanit wrote:
> Bjorn / Rafael,
> 
> On 10/13/2015 10:52 AM, Suravee Suthikulpanit wrote:
> >
> >On 09/14/2015 09:34 AM, Bjorn Helgaas wrote:
> >>[..]
> >>I think acpi_check_dma_coherency() is better, but only slightly.  It
> >>still doesn't give a hint about the *sense* of the return value.  I
> >>think it'd be easier to read if there were two functions, e.g.,
> >
> >I have been going back-and-forth between the current version, and the
> >two-function-approach in the past. I can definitely go with this route
> >if you would prefer. Although, if acpi_dma_is_coherent() == 0, it would
> >be ambiguous whether DMA is not supported or non-coherent DMA is
> >supported. Then, we would need to call acpi_dma_is_supported() to find
> >out. So, that's okay with you?
> 
> Thinking about this again, I still think having one API (which can
> tell whether DMA is supported or not, and if so whether it is
> coherent or non-coherent) would be the least confusing and least
> error prone.
> 
> What if we would just have:
> 
> enum dev_dma_type acpi_get_dev_dma_type(struct acpi_device *adev);
> 
> where:
> enum dev_dma_type {
> DEV_DMA_NOT_SUPPORTED,
> DEV_DMA_NON_COHERENT,
> DEV_DMA_COHERENT,
> };
> 
> This would probably mean that we should modify
> drivers/base/property.c to replace:
> bool device_dma_is_coherent()
> to:
> enum dev_dma_type device_get_dma_type()
> 
> We used to discuss the enum approach in the past
> (https://lkml.org/lkml/2015/8/25/868). But we only considered at the
> ACPI level at the time. Actually, this should also reflect in the
> property.c.
> 
> At this point, only drivers/crypto/ccp/ccp-platform.c and
> drivers/net/ethernet/amd/xgbe/xgbe-main.c are calling the
> device_dma_is_coherent(). So, it should be easy to change this API.

OK, I'm fine with either the enum or Rafael's 0/1/-ENOTSUPP idea.

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

Re: [PATCH v2 1/3] perf help: Add options description to 'perf -h'

[Yunlong Song]

On 2015/10/19 23:29, Namhyung Kim wrote:
> Hi,
> 
> On Thu, Oct 15, 2015 at 03:39:50PM +0800, Yunlong Song wrote:
>> Add options description to 'perf -h' to make it consistent with other 
>> builtins
>> (e.g., 'perf stat -h').
>>
>> Example:
>>
>> Before this patch:
>>
>>  # perf -h
>>
>>  usage: perf [--version] [--help] [OPTIONS] COMMAND [ARGS]
>>
>>   The most commonly used perf commands are:
>> annotateRead perf.data (created by perf record) and display 
>> annotated code
>> archive Create archive with object files with build-ids found in 
>> perf.data file
>> bench   General framework for benchmark suites
>> buildid-cache   Manage build-id cache.
>> buildid-listList the buildids in a perf.data file
>>  
>> testRuns sanity tests.
>> timechart   Tool to visualize total system behavior during a workload
>> top System profiling tool.
>> trace   strace inspired tool
>> probe   Define new dynamic tracepoints
>>
>>   See 'perf help COMMAND' for more information on a specific command.
>>
>> After this patch:
>>
>>  # perf -h
>>
>>   usage: perf [--version] [--help] [OPTIONS] COMMAND [ARGS]
>>
>>  --helphelp
>>  --version version
>>  --exec-path   exec-path
>>  --html-path   html-path
>>  --paginatepaginate
>>  --no-pagerno-pager
>>  --perf-dirperf-dir
>>  --work-tree   work-tree
>>  --debugfs-dir debugfs-dir
>>  --buildid-dir buildid-dir
>>  --list-cmds   list-cmds
>>  --list-opts   list-opts
>>  --debug   debug
> 
> IMHO this *help* message is not very useful in its current form.  Also
> please consider updating Documentation/perf.txt too.
> 
> Thanks,
> Namhyung

OK, I will update the struct option of perf to a more interpretative style soon.

> 
>>
>>   The most commonly used perf commands are:
>> annotateRead perf.data (created by perf record) and display 
>> annotated code
>> archive Create archive with object files with build-ids found in 
>> perf.data file
>> bench   General framework for benchmark suites
>> buildid-cache   Manage build-id cache.
>> buildid-listList the buildids in a perf.data file
>>  
>> testRuns sanity tests.
>> timechart   Tool to visualize total system behavior during a workload
>> top System profiling tool.
>> trace   strace inspired tool
>> probe   Define new dynamic tracepoints
>>
>>   See 'perf help COMMAND' for more information on a specific command.
>>
>> As shown above, the options description really appears now.
>>
>> Signed-off-by: Yunlong Song 
> 
> .
> 


-- 
Thanks,
Yunlong Song

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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/1] bpf: control events stored in PERF_EVENT_ARRAY maps trace data output when perf sampling

[Alexei Starovoitov]

On 10/19/15 3:37 AM, Kaixu Xia wrote:

+/* flags for PERF_EVENT_ARRAY maps*/
+enum {
+   BPF_EVENT_CTL_BIT_CUR = 0,
+   BPF_EVENT_CTL_BIT_ALL = 1,
+   __NR_BPF_EVENT_CTL_BITS,
+};
+
+#defineBPF_CTL_BIT_FLAG_MASK \
+   ((1ULL << __NR_BPF_EVENT_CTL_BITS) - 1)
+#defineBPF_CTL_BIT_DUMP_CUR \
+   (1ULL << BPF_EVENT_CTL_BIT_CUR)
+#defineBPF_CTL_BIT_DUMP_ALL \
+   (1ULL << BPF_EVENT_CTL_BIT_ALL)
+


the above shouldn't be part of uapi header. It can stay in bpf_trace.c
Just document these bits next to helper similar to skb_store_bytes()

The rest looks ok.
It still needs an ack from Peter for perf_event bits

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

Re: [PATCH v6 0/17] Add Analogix Core Display Port Driver

[Yakir Yang]

Hi Javier,

On 10/19/2015 06:40 PM, Javier Martinez Canillas wrote:

Hello Yakir,

On 10/10/2015 05:35 PM, Yakir Yang wrote:

Hi all,

The Samsung Exynos eDP controller and Rockchip RK3288 eDP controller
share the same IP, so a lot of parts can be re-used. I split the common
code into bridge directory, then rk3288 and exynos only need to keep
some platform code. Cause I can't find the exact IP name of exynos dp
controller, so I decide to name dp core driver with "analogix" which I
find in rk3288 eDP TRM :)

But  there are still three light registers setting differents bewteen
exynos and rk3288.
1. RK3288 have five special pll resigters which not indicata in exynos
dp controller.
2. The address of DP_PHY_PD(dp phy power manager register) are different
between rk3288 and exynos.
3. Rk3288 and exynos have different setting with AUX_HW_RETRY_CTL(dp debug
register).

This series have been well tested on Rockchip platform with eDP panel
on Jerry Chromebook and Display Port Monitor on RK3288 board and thanks
to Javier@Samsung help me to find a way to install mainline kernel to
Samsung Exynos Chromebooks, so this series also have been tested on Samsung
Snow and Peach Pit Chromebooks which borrowed from my friends.

Besides, This version was build on linux-next branch (tag next-20150918), and
the above test experiments also base on that tag. But I know the latest tag is
next-20151009, so i do rebase this series again on next-20151009, there were
little conflicts(exynos_dp removed the suspend/resume).

But after I retest this series on next-20151009, I saw kernel crashed in mmc
driver(dw_mci_probe failed to get regulator). So i have to disabled the MMC
module(after all I boot with USB device), and I can see eDP light up normally
in startup stage, but kernel keep crashed when it try to mount the filesystem.
I thought this isn't related to dp driver directly, so i choice not to debug
more depth.

That's to say if someone want to test this series, I suggest you applied this
series on tag-20150918, just need to fix some light conflicts with the 01 & 02
patches (or just email me, I can send you directly).

Thanks,

Do you have a branch that I can use to test this series?


Thank you for your kind assistance, I have created a tree which checkout 
from the next-20151019. Surely there were some conflicts to applied this 
series on that tag, but things still works for me, here is the git 
address [https://github.com/yakir-Yang/linux/tree/analogix_dp]


Best regards,
- Yakir



Best regards,



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

linux-next: manual merge of the tip tree with the dt-rh tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the tip tree got a conflict in:

  include/linux/of_irq.h

between commits:

  f9f9f11dcf0f ("of/irq: move of_msi_configure to the right guard and add a 
dummy")
  52493d446141 ("of/irq: make of_irq_find_parent static")

from the dt-rh tree and commit:

  8db02d8b4089 ("of/irq: Add new function of_msi_map_rid()")
  48ae34fb39b0 ("of/irq: Add support code for multi-parent version of 
"msi-parent"")
  82b9b4243c6d ("of/irq: Use the msi-map property to provide device-specific 
MSI domain")

from the tip tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

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

diff --cc include/linux/of_irq.h
index 580818d90475,65d969246a4d..
--- a/include/linux/of_irq.h
+++ b/include/linux/of_irq.h
@@@ -46,7 -46,11 +46,12 @@@ extern int of_irq_get(struct device_nod
  extern int of_irq_get_byname(struct device_node *dev, const char *name);
  extern int of_irq_to_resource_table(struct device_node *dev,
struct resource *res, int nr_irqs);
 +extern void of_msi_configure(struct device *dev, struct device_node *np);
+ extern struct irq_domain *of_msi_get_domain(struct device *dev,
+   struct device_node *np,
+   enum irq_domain_bus_token token);
+ extern struct irq_domain *of_msi_map_get_device_domain(struct device *dev,
+  u32 rid);
  #else
  static inline int of_irq_count(struct device_node *dev)
  {
@@@ -65,25 -69,47 +70,43 @@@ static inline int of_irq_to_resource_ta
  {
return 0;
  }
 +static inline void of_msi_configure(struct device *dev, struct device_node 
*np)
 +{
 +}
+ static inline struct irq_domain *of_msi_get_domain(struct device *dev,
+  struct device_node *np,
+  enum irq_domain_bus_token 
token)
+ {
+   return NULL;
+ }
+ static inline struct irq_domain *of_msi_map_get_device_domain(struct device 
*dev,
+ u32 rid)
+ {
+   return NULL;
+ }
  #endif
  
 -#if defined(CONFIG_OF)
 +#if defined(CONFIG_OF_IRQ) || defined(CONFIG_SPARC)
  /*
   * irq_of_parse_and_map() is used by all OF enabled platforms; but SPARC
   * implements it differently.  However, the prototype is the same for all,
   * so declare it here regardless of the CONFIG_OF_IRQ setting.
   */
  extern unsigned int irq_of_parse_and_map(struct device_node *node, int index);
 -extern struct device_node *of_irq_find_parent(struct device_node *child);
 -extern void of_msi_configure(struct device *dev, struct device_node *np);
+ u32 of_msi_map_rid(struct device *dev, struct device_node *msi_np, u32 
rid_in);
  
 -#else /* !CONFIG_OF */
 +#else /* !CONFIG_OF && !CONFIG_SPARC */
  static inline unsigned int irq_of_parse_and_map(struct device_node *dev,
int index)
  {
return 0;
  }
+ 
 -static inline void *of_irq_find_parent(struct device_node *child)
 -{
 -  return NULL;
 -}
 -
+ static inline u32 of_msi_map_rid(struct device *dev,
+struct device_node *msi_np, u32 rid_in)
+ {
+   return rid_in;
+ }
  #endif /* !CONFIG_OF */
  
  #endif /* __OF_IRQ_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 v2 09/14] ACPICA: Debugger: Fix "quit/exit" command by cleaning up user commands termination logic

[Zheng, Lv]

I was using linux-pm.git/linux-next base which I downloaded a week ago.
Maybe the conflict was caused by the fast-path ACPICA table fix merged after my 
downloading.
Let me check again.

Thanks and best regards
-Lv

> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Tuesday, October 20, 2015 5:04 AM
> 
> On Monday, October 19, 2015 10:25:32 AM Lv Zheng wrote:
> > ACPICA commit 0dd68e16274cd38224aa4781eddc57dc2cbaa108
> >
> > The quit/exit commands shouldn't invoke acpi_terminate_debugger() and
> > acpi_terminate() right in the user command loop, because when the debugger
> > exits, the kernel ACPI subsystem shouldn't be terminated (acpi_terminate())
> > and the debugger should only be terminated by its users
> > (acpi_terminate_debugger()) rather than being terminated itself. Leaving 
> > such
> > invocations causes kernel panic when the debugger is shipped in the Linux
> > kernel.
> >
> > This patch fixes this issue. Lv Zheng.
> >
> > Link: https://github.com/acpica/acpica/commit/0dd68e16
> > Signed-off-by: Lv Zheng 
> > Signed-off-by: Bob Moore 
> 
> This patch does not apply for me on top of the current mainline.
> 
> What tree is it applicable to?
> 
> Thanks,
> Rafael

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

Re: [PATCH 0/3] hugetlbfs fallocate hole punch race with page faults

[Mike Kravetz]

On 10/19/2015 04:18 PM, Andrew Morton wrote:
> On Fri, 16 Oct 2015 15:08:27 -0700 Mike Kravetz  
> wrote:
> 
>> The hugetlbfs fallocate hole punch code can race with page faults.  The
>> result is that after a hole punch operation, pages may remain within the
>> hole.  No other side effects of this race were observed.
>>
>> In preparation for adding userfaultfd support to hugetlbfs, it is desirable
>> to plug or significantly shrink this hole.  This patch set uses the same
>> mechanism employed in shmem (see commit f00cdc6df7).
>>
> 
> "still buggy but not as bad as before" isn't what we strive for ;) What
> would it take to fix this for real?  An exhaustive description of the
> bug would be a good starting point, thanks.
> 

Thanks for asking, it made me look closer at ways to resolve this.

The current code in remove_inode_hugepages() does nothing with a page if
it is still mapped.  The only way it can be mapped is if we race and take
a page fault after unmapping, but before the page is removed.  This patch
set makes that window much smaller, but it still exists.

Instead of "giving up" on a mapped page, remove_inode_hugepages() can go
back and unmap it.  I'll code this up tomorrow.  Fortunately, it is
pretty easy to hit these races and verify proper behavior.

I'll create a new patch set with this combined code for a complete fix.

-- 
Mike Kravetz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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/3] Thermal: do thermal zone update after a cooling device registered

[Chen, Yu C]

(resend for broken display)

Hi,
> -Original Message-
> From: Javi Merino [mailto:javi.mer...@arm.com]
> Sent: Thursday, October 15, 2015 10:05 PM
> To: Chen, Yu C
> Cc: linux...@vger.kernel.org; edubez...@gmail.com; Zhang, Rui; linux- 
> ker...@vger.kernel.org; sta...@vger.kernel.org; Pandruvada, Srinivas
> Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a 
> cooling device registered
> 
> On Wed, Oct 14, 2015 at 07:23:55PM +, Chen, Yu C wrote:
> > > -Original Message-
> > > From: Javi Merino [mailto:javi.mer...@arm.com]
> > > Sent: Thursday, October 15, 2015 1:08 AM
> > > To: Chen, Yu C
> > > Cc: linux...@vger.kernel.org; edubez...@gmail.com; Zhang, Rui;
> > > linux- ker...@vger.kernel.org; sta...@vger.kernel.org; Pandruvada, 
> > > Srinivas
> > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a 
> > > cooling device registered
> > >
> > > On Mon, Oct 12, 2015 at 09:23:28AM +, Chen, Yu C wrote:
> > > > Hi, Javi
> > > > Sorry for my late response,
> > > >
> > > > > -Original Message-
> > > > > From: Javi Merino [mailto:javi.mer...@arm.com]
> > > > > Sent: Wednesday, September 30, 2015 12:02 AM
> > > > > To: Chen, Yu C
> > > > > Cc: linux...@vger.kernel.org; edubez...@gmail.com; Zhang, Rui;
> > > > > linux- ker...@vger.kernel.org; sta...@vger.kernel.org
> > > > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after 
> > > > > a cooling device registered
> > > > >
> > > > > Hi Yu,
> > > > >
> > > > > On Mon, Sep 28, 2015 at 06:52:00PM +0100, Chen, Yu C wrote:
> > > > > > Hi, Javi,
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Javi Merino [mailto:javi.mer...@arm.com]
> > > > > > > Sent: Monday, September 28, 2015 10:29 PM
> > > > > > > To: Chen, Yu C
> > > > > > > Cc: linux...@vger.kernel.org; edubez...@gmail.com; Zhang, 
> > > > > > > Rui;
> > > > > > > linux- ker...@vger.kernel.org; sta...@vger.kernel.org
> > > > > > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update 
> > > > > > > after a cooling device registered
> > > > > > >
> > > > > > > On Sun, Sep 27, 2015 at 06:48:44AM +0100, Chen Yu wrote:
> > > > > > > > From: Zhang Rui 
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > I think you need to hold cdev->lock here, to make sure 
> > > > > > > that no thermal zone is added or removed from
> > > > > > > cdev->thermal_instances while
> > > > > you are looping.
> > > > > > >
> > > > > > Ah right, will add. If I add the cdev ->lock here, will 
> > > > > > there be a AB-BA lock with thermal_zone_unbind_cooling_device?
> > > > >
> > > > > You're right, it could lead to a deadlock.  The locks can't be 
> > > > > swapped because that won't work in step_wise.
> > > > >
> > > > > The best way that I can think of accessing thermal_instances 
> > > > > atomically is by making it RCU protected instead of with mutexes.
> > > > > What do you think?
> > > > >
> > > > RCU would need extra spinlocks to protect the list, and need to 
> > > > sync_rcu after we delete one instance from thermal_instance 
> > > > list, I think it is too complicated for me to rewrite: ( How 
> > > > about using
> > > thermal_list_lock instead of cdev ->lock?
> > > > This guy should be big enough to protect the 
> > > > device.thermal_instance
> list.
> > >
> > > thermal_list_lock protects thermal_tz_list and thermal_cdev_list, 
> > > but it doesn't protect the thermal_instances list.  For example,
> > > thermal_zone_bind_cooling_device() adds a cooling device to the
> > > cdev->thermal_instances list without taking thermal_tz_list.
> > >
> > Before thermal_zone_bind_cooling_device is invoked, the 
> > thermal_list_lock will be firstly gripped:
> >
> > static void bind_cdev(struct thermal_cooling_device *cdev) { 
> > mutex_lock(_list_lock);
> > either tz->ops->bind:   thermal_zone_bind_cooling_device
> > or __bind()  :   thermal_zone_bind_cooling_device
> > mutex_unlock(_list_lock);
> > }
> >
> > And it is the same as in  passive_store.
> > So when code is trying to add/delete thermal_instance of cdev, he 
> > has already hold thermal_list_lock IMO. Or do I miss anything?
> 
> thermal_zone_bind_cooling_device() is exported, so you can't really 
> rely on the static thermal_list_lock being acquired in every single call.
> 
> thermal_list_lock and protects the lists thermal_tz_list and 
> thermal_cdev_list.
> Making it implicitly protect the cooling device's and thermal zone 
> device's instances list because no sensible code would call
> thermal_zone_bind_cooling_device() outside of a bind function is just 
> asking for trouble.
> 
Yes, from this point of view,it is true. 

> Locking is hard to understand and easy to get wrong so let's keep it simple.
> 
How about the following 2 methods:
1. avoid accessing device's thermal_instance,
but access all thermal_zone_device directly,
 although there might be some redundancy,
 some thermal zones do not need to be updated, 
but we can avoid gripping dev->lock:

Re: [PATCH] mm: Introduce kernelcore=reliable option

[Xishi Qiu]

On 2015/10/20 8:34, Izumi, Taku wrote:

>  Hi Xishi,
> 
>> On 2015/10/15 21:32, Taku Izumi wrote:
>>
>>> Xeon E7 v3 based systems supports Address Range Mirroring
>>> and UEFI BIOS complied with UEFI spec 2.5 can notify which
>>> ranges are reliable (mirrored) via EFI memory map.
>>> Now Linux kernel utilize its information and allocates
>>> boot time memory from reliable region.
>>>
>>> My requirement is:
>>>   - allocate kernel memory from reliable region
>>>   - allocate user memory from non-reliable region
>>>
>>> In order to meet my requirement, ZONE_MOVABLE is useful.
>>> By arranging non-reliable range into ZONE_MOVABLE,
>>> reliable memory is only used for kernel allocations.
>>>
>>> This patch extends existing "kernelcore" option and
>>> introduces kernelcore=reliable option. By specifying
>>> "reliable" instead of specifying the amount of memory,
>>> non-reliable region will be arranged into ZONE_MOVABLE.
>>>
>>> Earlier discussion is at:
>>>  https://lkml.org/lkml/2015/10/9/24
>>>
>>
>> Hi Taku,
>>
>> If user don't want to waste a lot of memory, and he only set
>> a few memory to mirrored memory, then the kernelcore is very
>> small, right? That means OS will have a very small normal zone
>> and a very large movable zone.
> 
>  Right.
> 
>> Kernel allocation could only use the unmovable zone. As the
>> normal zone is very small, the kernel allocation maybe OOM,
>> right?
> 
>  Right.
> 
>> Do you mean that we will reuse the movable zone in short-term
>> solution and create a new zone(mirrored zone) in future?
> 
>  If there is that kind of requirements, I don't oppose 
>  creating a new zone.
> 

As far as I know, some apps(e.g. date base) maybe could only use
the normal zone.

Thanks,
Xishi Qiu

>  Sincerely,
>  Taku Izumi
> 
> .
> 



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] mm/hugetlb: Setup hugetlb_falloc during fallocate hole punch

[Mike Kravetz]

On 10/19/2015 04:16 PM, Andrew Morton wrote:
> On Fri, 16 Oct 2015 15:08:29 -0700 Mike Kravetz  
> wrote:
> 
>> When performing a fallocate hole punch, set up a hugetlb_falloc struct
>> and make i_private point to it.  i_private will point to this struct for
>> the duration of the operation.  At the end of the operation, wake up
>> anyone who faulted on the hole and is on the waitq.
>>
>> ...
>>
>> --- a/fs/hugetlbfs/inode.c
>> +++ b/fs/hugetlbfs/inode.c
>> @@ -507,7 +507,9 @@ static long hugetlbfs_punch_hole(struct inode *inode, 
>> loff_t offset, loff_t len)
>>  {
>>  struct hstate *h = hstate_inode(inode);
>>  loff_t hpage_size = huge_page_size(h);
>> +unsigned long hpage_shift = huge_page_shift(h);
>>  loff_t hole_start, hole_end;
>> +struct hugetlb_falloc hugetlb_falloc;
>>  
>>  /*
>>   * For hole punch round up the beginning offset of the hole and
>> @@ -518,8 +520,23 @@ static long hugetlbfs_punch_hole(struct inode *inode, 
>> loff_t offset, loff_t len)
>>  
>>  if (hole_end > hole_start) {
>>  struct address_space *mapping = inode->i_mapping;
>> +DECLARE_WAIT_QUEUE_HEAD_ONSTACK(hugetlb_falloc_waitq);
>> +
>> +/*
>> + * Page faults on the area to be hole punched must be
>> + * stopped during the operation.  Initialize struct and
>> + * have inode->i_private point to it.
>> + */
>> +hugetlb_falloc.waitq = _falloc_waitq;
>> +hugetlb_falloc.start = hole_start >> hpage_shift;
>> +hugetlb_falloc.end = hole_end >> hpage_shift;
> 
> This is a bit neater:
> 
> --- 
> a/fs/hugetlbfs/inode.c~mm-hugetlb-setup-hugetlb_falloc-during-fallocate-hole-punch-fix
> +++ a/fs/hugetlbfs/inode.c
> @@ -509,7 +509,6 @@ static long hugetlbfs_punch_hole(struct
>   loff_t hpage_size = huge_page_size(h);
>   unsigned long hpage_shift = huge_page_shift(h);
>   loff_t hole_start, hole_end;
> - struct hugetlb_falloc hugetlb_falloc;
>  
>   /*
>* For hole punch round up the beginning offset of the hole and
> @@ -521,15 +520,16 @@ static long hugetlbfs_punch_hole(struct
>   if (hole_end > hole_start) {
>   struct address_space *mapping = inode->i_mapping;
>   DECLARE_WAIT_QUEUE_HEAD_ONSTACK(hugetlb_falloc_waitq);
> -
>   /*
> -  * Page faults on the area to be hole punched must be
> -  * stopped during the operation.  Initialize struct and
> -  * have inode->i_private point to it.
> +  * Page faults on the area to be hole punched must be stopped
> +  * during the operation.  Initialize struct and have
> +  * inode->i_private point to it.
>*/
> - hugetlb_falloc.waitq = _falloc_waitq;
> - hugetlb_falloc.start = hole_start >> hpage_shift;
> - hugetlb_falloc.end = hole_end >> hpage_shift;
> + struct hugetlb_falloc hugetlb_falloc = {
> + .waitq = _falloc_waitq,
> + .start = hole_start >> hpage_shift,
> + .end = hole_end >> hpage_shift
> + };
>  
>   mutex_lock(>i_mutex);
>  
> 

Thanks!

>>  mutex_lock(>i_mutex);
>> +
>> +spin_lock(>i_lock);
>> +inode->i_private = _falloc;
>> +spin_unlock(>i_lock);
> 
> Locking around a single atomic assignment is a bit peculiar.  I can
> kinda see that it kinda protects the logic in hugetlb_fault(), but I
> would like to hear (in comment form) your description of how this logic
> works?

To be honest, this code/scheme was copied from shmem as it addresses
the same situation there.  I did not notice how strange this looks until
you pointed it out.  At first glance, the locking does appear to be
unnecessary.  The fault code initially checks this value outside the
lock.  However, the fault code (on another CPU) will take the lock
and access values within the structure.  Without the locking or some other
type of memory barrier here, there is no guarantee that the structure
will be initialized before setting i_private.  So, the faulting code
could see invalid values in the structure.

Hugh, is that accurate?  You provided the shmem code.

-- 
Mike Kravetz

>>  i_mmap_lock_write(mapping);
>>  if (!RB_EMPTY_ROOT(>i_mmap))
>>  hugetlb_vmdelete_list(>i_mmap,
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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/5] MADV_FREE refactoring and fix KSM page

[Minchan Kim]

On Mon, Oct 19, 2015 at 07:01:50PM +0900, Minchan Kim wrote:
> On Mon, Oct 19, 2015 at 03:31:42PM +0900, Minchan Kim wrote:
> > Hello, it's too late since I sent previos patch.
> > https://lkml.org/lkml/2015/6/3/37
> > 
> > This patch is alomost new compared to previos approach.
> > I think this is more simple, clear and easy to review.
> > 
> > One thing I should notice is that I have tested this patch
> > and couldn't find any critical problem so I rebased patchset
> > onto recent mmotm(ie, mmotm-2015-10-15-15-20) to send formal
> > patchset. Unfortunately, I start to see sudden discarding of
> > the page we shouldn't do. IOW, application's valid anonymous page
> > was disappeared suddenly.
> > 
> > When I look through THP changes, I think we could lose
> > dirty bit of pte between freeze_page and unfreeze_page
> > when we mark it as migration entry and restore it.
> > So, I added below simple code without enough considering
> > and cannot see the problem any more.
> > I hope it's good hint to find right fix this problem.
> > 
> > diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> > index d5ea516ffb54..e881c04f5950 100644
> > --- a/mm/huge_memory.c
> > +++ b/mm/huge_memory.c
> > @@ -3138,6 +3138,9 @@ static void unfreeze_page_vma(struct vm_area_struct 
> > *vma, struct page *page,
> > if (is_write_migration_entry(swp_entry))
> > entry = maybe_mkwrite(entry, vma);
> >  
> > +   if (PageDirty(page))
> > +   SetPageDirty(page);
> 
> The condition of PageDirty was typo. I didn't add the condition.
> Just added.
> 
> SetPageDirty(page);

For the first step to find this bug, I removed all MADV_FREE related
code in mmotm-2015-10-15-15-20. IOW, git checkout 54bad5da4834
(arm64: add pmd_[dirty|mkclean] for THP) so the tree doesn't have
any core code of MADV_FREE.

I tested following workloads in my KVM machine.

0. make memcg
1. limit memcg
2. fork several processes
3. each process allocates THP page and fill
4. increase limit of the memcg to swapoff successfully
5. swapoff
6. kill all of processes
7. goto 1

Within a few hours, I encounter following bug.
Attached detailed boot log and dmesg result.


Initializing cgroup subsys cpu
Command line: hung_task_panic=1 earlyprintk=ttyS0,115200 debug apic=debug 
sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=-1 
softlockup_panic=1 nmi_watchdog=panic oops=panic console=ttyS0,115200 
console=tty0 earlyprintk=ttyS0 ignore_loglevel ftrace_dump_on_oops vga=normal 
root=/dev/vda1 rw
KERNEL supported cpus:
  Intel GenuineIntel
x86/fpu: Legacy x87 FPU detected.
x86/fpu: Using 'lazy' FPU context switches.
e820: BIOS-provided physical RAM map:
BIOS-e820: [mem 0x-0x0009fbff] usable
BIOS-e820: [mem 0x0009fc00-0x0009] reserved
BIOS-e820: [mem 0x000f-0x000f] reserved
BIOS-e820: [mem 0x0010-0xbfffbfff] usable
BIOS-e820: [mem 0xbfffc000-0xbfff] reserved
BIOS-e820: [mem 0xfeffc000-0xfeff] reserved
BIOS-e820: [mem 0xfffc-0x] reserved



Adding 4191228k swap on /dev/vda5.  Priority:-1 extents:1 across:4191228k FS
Adding 4191228k swap on /dev/vda5.  Priority:-1 extents:1 across:4191228k FS
Adding 4191228k swap on /dev/vda5.  Priority:-1 extents:1 across:4191228k FS
Adding 4191228k swap on /dev/vda5.  Priority:-1 extents:1 across:4191228k FS
Adding 4191228k swap on /dev/vda5.  Priority:-1 extents:1 across:4191228k FS
Adding 4191228k swap on /dev/vda5.  Priority:-1 extents:1 across:4191228k FS
Adding 4191228k swap on /dev/vda5.  Priority:-1 extents:1 across:4191228k FS
Adding 4191228k swap on /dev/vda5.  Priority:-1 extents:1 across:4191228k FS
Adding 4191228k swap on /dev/vda5.  Priority:-1 extents:1 across:4191228k FS
Adding 4191228k swap on /dev/vda5.  Priority:-1 extents:1 across:4191228k FS
Adding 4191228k swap on /dev/vda5.  Priority:-1 extents:1 across:4191228k FS
Adding 4191228k swap on /dev/vda5.  Priority:-1 extents:1 across:4191228k FS
Adding 4191228k swap on /dev/vda5.  Priority:-1 extents:1 across:4191228k FS
BUG: unable to handle kernel NULL pointer dereference at 0008
IP: [] down_read_trylock+0x9/0x30
PGD 0 
Oops:  [#1] SMP 
Dumping ftrace buffer:
   (ftrace buffer empty)
Modules linked in:
CPU: 1 PID: 26445 Comm: sh Not tainted 4.3.0-rc5-mm1-diet-meta+ #1545
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 8800b9af3480 ti: 88007fea task.ti: 88007fea
RIP: 0010:[]  [] down_read_trylock+0x9/0x30
RSP: 0018:88007fea3648  EFLAGS: 00010202
RAX: 0001 RBX: ea0002324900 RCX: 88007fea37e8
RDX:  RSI: 88007fea36e8 RDI: 0008
RBP: 88007fea3648 R08: 818446a0 R09: 8800b9af4c80
R10: 0216 R11: 0001 R12: 88007f58d6e1
R13: 88007f58d6e0 R14: 0008 R15: 0001
FS:  

Re: [PATCH 0/4] PCI: rcar: Add support for ARM64 and multiple instances

[Simon Horman]

On Mon, Oct 19, 2015 at 06:16:34PM -0500, Bjorn Helgaas wrote:
> [+cc Geert]
> 
> On Fri, Oct 02, 2015 at 11:25:03AM +0100, Phil Edworthy wrote:
> > Fixes and changes to get PCIe working on ARM64 with mulitple instances.
> > 
> > I've tested these on ARM (Koelsch board), and it works fine.
> > I've also tested on ARM64 (Salvator-X board), but I currently have an issue
> > with inbound PCI accesses. I am reasonably sure that this problem is 
> > hardware
> > related.
> > 
> > Phil Edworthy (4):
> >   PCI: rcar-pcie: Make PCI aware of the IO resources
> >   PCI: rcar-pcie: Remove dependency on ARM-specific struct hw_pci
> >   PCI: rcar-pcie: Set root bus nr to that provided in DT
> >   PCI: rcar-pcie: Fix IO offset for multiple instances
> 
> I applied these with Simon's ack to pci/host-rcar for v4.4.
> 
> Note that these are on top of Geert's patch to make rcar build only
> for ARM, which is probably not necessary after you remove the struct
> hw_pci dependency.  I can drop Geert's patch if you want.

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

Re: [RFC] hwmon: ina2xx: allow for actual measurement bandwidth above 160 Hz

[Guenter Roeck]

On 10/19/2015 09:21 AM, Marc Titinger wrote:

With the current implementation, the driver will prevent a readout at a
pace faster than the default conversion time (2ms) times the averaging
setting, min AVG being 1:1.

Any sysfs "show" read access from the client app faster than 500 Hz will be
'cached' by the driver, but actually since do_update reads all 8 registers,
the best achievable measurement rate is roughly 8*800 us (for the time
spent in i2c-core) i.e. <= 156Hz with Beagle Bone Black.

This change set uses a register mask to allow for the readout of a single
i2c register at a time. Furthermore, performing subsequent reads on the
same register will make use of the ability of the i2c chip to retain the
last reg offset, hence use a shorter i2c message (roughly 400us instead of
800us spent in i2c-core.c).

The best readout rate for a single measurement is now around 2kHz. And for
four measurements around (1/(4*800us) = 312 Hz. Since for any readout rate
faster than 160 Hz the interval is set by the i2c transactions completion,
the 'last-update' anti-flooding code will not have a limiting effect in
practice. Hence I also remove the elapsed time checking in the hwmon driver
for ina2xx.

To summarize, the patch provides a max bandwidth improvement with hwmon
client apps from ~160 Hz to ~320 Hz, and better in single-channel
polling mode.



I really dislike that complexity. Maybe we should drop caching entirely
in this driver ? Maybe even convert it to use regmap ?

Guenter


Signed-off-by: Marc Titinger 
---
  drivers/hwmon/ina2xx.c | 90 +++---
  1 file changed, 71 insertions(+), 19 deletions(-)

diff --git a/drivers/hwmon/ina2xx.c b/drivers/hwmon/ina2xx.c
index 4d28150..ce3a2ee 100644
--- a/drivers/hwmon/ina2xx.c
+++ b/drivers/hwmon/ina2xx.c
@@ -48,6 +48,8 @@
  #define INA2XX_CURRENT0x04 /* readonly */
  #define INA2XX_CALIBRATION0x05

+#define BITPOS_TO_MASK(x) (1L << x)
+
  /* INA226 register definitions */
  #define INA226_MASK_ENABLE0x06
  #define INA226_ALERT_LIMIT0x07
@@ -105,9 +107,14 @@ struct ina2xx_data {

struct mutex update_lock;
bool valid;
-   unsigned long last_updated;
int update_interval; /* in jiffies */

+   /* Last read register (slave address already set
+* reading out from this same register repeatedly will
+* be significantly faster!
+*/
+   int last_reg;
+
int kind;
const struct attribute_group *groups[INA2XX_MAX_ATTRIBUTE_GROUPS];
u16 regs[INA2XX_MAX_REGISTERS];
@@ -203,21 +210,63 @@ static int ina2xx_init(struct ina2xx_data *data)
return ina2xx_calibrate(data);
  }

-static int ina2xx_do_update(struct device *dev)
+/*
+ * Most I2c chips will allow reading from the current register pointer
+ * w/o setting the register offset again.
+ */
+static inline s32 __i2c_read_same_word(const struct i2c_client *client)
+{
+   unsigned char msgbuf[2];
+
+   struct i2c_msg msg = {
+   .addr = client->addr,
+   .flags = client->flags | I2C_M_RD,
+   .len = 2,
+   .buf = msgbuf,
+   };
+
+   int status = i2c_transfer(client->adapter, , 1);
+
+   return (status < 0) ? status : (msgbuf[1]|(msgbuf[0]<<8));
+}
+
+static int ina2xx_do_update(struct device *dev, int reg_mask)
  {
struct ina2xx_data *data = dev_get_drvdata(dev);
struct i2c_client *client = data->client;
-   int i, rv, retry;
+   int i = 0, rv, retry;

dev_dbg(>dev, "Starting ina2xx update\n");

for (retry = 5; retry; retry--) {
-   /* Read all registers */
-   for (i = 0; i < data->config->registers; i++) {
-   rv = i2c_smbus_read_word_swapped(client, i);
+
+   /* Try to issue a shorter i2c message */
+   if (reg_mask & (1 << data->last_reg)) {
+   rv = __i2c_read_same_word(client);
if (rv < 0)
return rv;
-   data->regs[i] = rv;
+
+   reg_mask &= ~(1 << data->last_reg);
+   data->regs[data->last_reg] = rv;
+
+   dev_dbg(>dev, "%d, rv = %x, (last_reg)\n",
+   data->last_reg,
+   data->regs[data->last_reg]);
+   }
+
+   /* Check for remaining registers in mask. */
+   while (reg_mask && i < data->config->registers) {
+   if (reg_mask & (1L << i)) {
+   rv = i2c_smbus_read_word_swapped(client, i);
+   if (rv < 0)
+   return rv;
+   data->regs[i] = rv;
+   data->last_reg = i;
+
+   dev_dbg(>dev, 

Re: ***SPAM*** [PATCH 4.1 000/202] 4.1.11-stable review

[Guenter Roeck]

On 10/19/2015 08:28 AM, Willy Tarreau wrote:

On Mon, Oct 19, 2015 at 08:14:12AM -0700, Greg Kroah-Hartman wrote:

Who added the "***SPAM***" prefix?


Since it was present in Guenter's response without corresponding spam
headers, I suspect it was added between vger and Gunter's mail server
on your announce and that he responded with it.



Yes, it was my internet provider's e-mail server. Sorry, I forgot to drop it.

Guenter

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

[PATCH v5] clk: add CS2000 Fractional-N driver

[Kuninori Morimoto]

From: Kuninori Morimoto 

This patch adds CS2000 Fractional-N driver as clock provider.

Signed-off-by: Kuninori Morimoto 
---
v4 -> v5

 - remove "clock-frequency"
 - use dev on clk_register()
 - remove CLK_IS_BASIC
 - .enable -> .prepare since it is using I2C
 . .disabe -> .unprepare since it is using I2C

 .../devicetree/bindings/clock/cs2000-cp.txt|  22 +
 drivers/clk/Kconfig|   6 +
 drivers/clk/Makefile   |   1 +
 drivers/clk/clk-cs2000-cp.c| 510 +
 4 files changed, 539 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/cs2000-cp.txt
 create mode 100644 drivers/clk/clk-cs2000-cp.c

diff --git a/Documentation/devicetree/bindings/clock/cs2000-cp.txt 
b/Documentation/devicetree/bindings/clock/cs2000-cp.txt
new file mode 100644
index 000..54e6df0
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/cs2000-cp.txt
@@ -0,0 +1,22 @@
+CIRRUS LOGIC Fractional-N Clock Synthesizer & Clock Multiplier
+
+Required properties:
+
+- compatible:  "cirrus,cs2000-cp"
+- reg: The chip select number on the I2C bus
+- clocks:  common clock binding for CLK_IN, XTI/REF_CLK
+- clock-names: CLK_IN : clk_in, XTI/REF_CLK : ref_clk
+- #clock-cells:must be <0>
+
+Example:
+
+ {
+   ...
+   cs2000: clk_multiplier@4f {
+   #clock-cells = <0>;
+   compatible = "cirrus,cs2000-cp";
+   reg = <0x4f>;
+   clocks = <_sound 0>, <_clk>;
+   clock-names = "clk_in", "ref_clk";
+   };
+};
diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 42f7120..0e961b2 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -95,6 +95,12 @@ config COMMON_CLK_CDCE925
  Given a target output frequency, the driver will set the PLL and
  divider to best approximate the desired output.
 
+config COMMON_CLK_CS2000_CP
+   tristate "Clock driver for CS2000 Fractional-N Clock Synthesizer & 
Clock Multiplier"
+   depends on I2C
+   help
+ If you say yes here you get support for the CS2000 clock multiplier.
+
 config COMMON_CLK_S2MPS11
tristate "Clock driver for S2MPS1X/S5M8767 MFD"
depends on MFD_SEC_CORE
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 9d31e2c..2fb77a8 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -21,6 +21,7 @@ obj-$(CONFIG_COMMON_CLK_AXI_CLKGEN)   += clk-axi-clkgen.o
 obj-$(CONFIG_ARCH_AXXIA)   += clk-axm5516.o
 obj-$(CONFIG_ARCH_BCM2835) += clk-bcm2835.o
 obj-$(CONFIG_COMMON_CLK_CDCE706)   += clk-cdce706.o
+obj-$(CONFIG_COMMON_CLK_CS2000_CP) += clk-cs2000-cp.o
 obj-$(CONFIG_ARCH_CLPS711X)+= clk-clps711x.o
 obj-$(CONFIG_ARCH_EFM32)   += clk-efm32gg.o
 obj-$(CONFIG_ARCH_HIGHBANK)+= clk-highbank.o
diff --git a/drivers/clk/clk-cs2000-cp.c b/drivers/clk/clk-cs2000-cp.c
new file mode 100644
index 000..71d9340
--- /dev/null
+++ b/drivers/clk/clk-cs2000-cp.c
@@ -0,0 +1,510 @@
+/*
+ * CS2000  --  CIRRUS LOGIC Fractional-N Clock Synthesizer & Clock Multiplier
+ *
+ * Copyright (C) 2015 Renesas Electronics Corporation
+ * Kuninori Morimoto 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CH_MAX 4
+
+#define DEVICE_ID  0x1
+#define DEVICE_CTRL0x2
+#define DEVICE_CFG10x3
+#define DEVICE_CFG20x4
+#define GLOBAL_CFG 0x5
+#define Ratio_Add(x, nth)  (6 + (x * 4) + (nth))
+#define Ratio_Val(x, nth)  ((x >> (24 - (8 * nth))) & 0xFF)
+#define Val_Ratio(x, nth)  ((x & 0xFF) << (24 - (8 * nth)))
+#define FUNC_CFG1  0x16
+#define FUNC_CFG2  0x17
+
+/* DEVICE_CTRL */
+#define PLL_UNLOCK (1 << 7)
+
+/* DEVICE_CFG1 */
+#define RSEL(x)(((x) & 0x3) << 3)
+#define RSEL_MASK  RSEL(0x3)
+#define ENDEV1 (0x1)
+
+/* GLOBAL_CFG */
+#define ENDEV2 (0x1)
+
+#define CH_SIZE_ERR(ch)((ch < 0) || (ch >= CH_MAX))
+#define hw_to_priv(_hw)container_of(_hw, struct cs2000_priv, 
hw)
+#define priv_to_client(priv)   (priv->client)
+#define priv_to_dev(priv)  (&(priv_to_client(priv)->dev))
+
+#define CLK_IN 0
+#define REF_CLK1
+#define CLK_MAX 2
+
+struct cs2000_priv {
+   struct clk_hw hw;
+   struct i2c_client *client;
+   struct clk *clk_in;
+   struct clk *ref_clk;
+   struct clk *clk_out;
+};
+
+static const struct of_device_id cs2000_of_match[] = {
+   { .compatible = "cirrus,cs2000-cp", },
+   {},
+};
+MODULE_DEVICE_TABLE(of, cs2000_of_match);
+
+static const struct i2c_device_id cs2000_id[] = {
+   { "cs2000-cp", },
+   {}
+};
+MODULE_DEVICE_TABLE(i2c, cs2000_id);

Re: [PATCH net-next 3/4] bpf: add support for persistent maps/progs

[Alexei Starovoitov]

On 10/19/15 4:02 PM, Hannes Frederic Sowa wrote:

I bet commercial software will make use of this ebpf framework, too. And
the kernel always helped me and gave me a way to see what is going on,
debug which part of my operating system universe interacts with which
other part. Merely dropping file descriptors with data attached to them
in an filesystem seems not to fulfill my need at all. I would love to
see where resources are referenced and why, like I am nowadays.


agree. common fs with hierarchy will give this visibility in
one place.


>It feels you're pushing for cdev only because of that potential
>debugging need. Did you actually face that need? I didn't and
>don't like to add 'nice to have' feature until real need comes.

Given that we want to monitor the load of a hashmap for graphing
purposes. Or liberate some hashmaps from its restriction on number of
keys and make upper bounds configurable by admins who know the
dimensions of their systems and not some software deep down buried in
the bpf syscall where I might not have access to source code. In tc
force e.g. hashmaps to do garbage collection because we cannot be sure
that under DoS attacks user space clean up gets scheduled early enough
if ebpf adds flows to hashtables. I do see need to expand and implement
some kind of policy in the future.


disagree here. admin should not interfere with map parameters.
What you proposing above sounds very very dangerous.
Admins to configure GC of maps? What do you think the programs will do
with such sophisticated maps? What kind of networking app you have
in mind? Anyway that's a bit off-topic. I'm very curious though.


>single task in seccomp can have a chain of bpf progs, so hierarchy
>is already there.

And it would be great to inspect them.


again let's not mix criu and lsof-like requirements with 'pin fd'.
For visibility of normal maps we can add fdinfo and lsof
can pick it up without any fs or any cdevs.


I am fine with creating maps only by bpf syscall. But to hide
configuration details or at least not be really able to query them
easily seems odd to me. If we go with the ebpffs how could those
attributes be added?


I'm not advocating to hide details. Most of the time maps will not be
pinned, so fdinfo seems the easiest way to show things like key_size,
value_size, max_entries, type.
Even if we decide to do it some other way, it's not related to 'pin fd'
discussion, since debugging/visibility is nice to have for all bpf 
objects. Note that walking of key/value without pretty-printers

provided by the app is meaningless for admin, so only things
like 'how much memory this map is using' are useful.

May be we should try to draft the hierarchy of this common fs.
How about:
/sys/kernel/bpf/username/optional_dirs_mkdir_by_user/progX
and 'cat' of it will print the same as fdinfo for normal maps,
so admin can see what maps were pinned by user and its cost.

Inside 'fdinfo' output we can provide pointers to which progs
are using which maps as
# cat /sys/kernel/bpf/.../mapX
key_size: 4
used_by: /proc/xxx/fd/5
# cat /sys/kernel/bpf/.../progY
type: socket
using: /proc/xxx/fd/6
using: /sys/kernel/bpf/.../mapZ
and similar for cat /proc/xxx/fdinfo/6
but showing hierarchy as directories is non starter, since
it's no a tree.

All of these would be nice, but doesn't have to be implemented
along with 'pin fd' feature.

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

[PATCH 3.4 01/65] hrtimer: Allow concurrent hrtimer_start() for self restarting timers

[lizf]

From: Peter Zijlstra 

3.4.110-rc1 review patch.  If anyone has any objections, please let me know.

--


commit 5de2755c8c8b3a6b8414870e2c284914a2b42e4d upstream.

Because we drop cpu_base->lock around calling hrtimer::function, it is
possible for hrtimer_start() to come in between and enqueue the timer.

If hrtimer::function then returns HRTIMER_RESTART we'll hit the BUG_ON
because HRTIMER_STATE_ENQUEUED will be set.

Since the above is a perfectly valid scenario, remove the BUG_ON and
make the enqueue_hrtimer() call conditional on the timer not being
enqueued already.

NOTE: in that concurrent scenario its entirely common for both sites
to want to modify the hrtimer, since hrtimers don't provide
serialization themselves be sure to provide some such that the
hrtimer::function and the hrtimer_start() caller don't both try and
fudge the expiration state at the same time.

To that effect, add a WARN when someone tries to forward an already
enqueued timer, the most common way to change the expiry of self
restarting timers. Ideally we'd put the WARN in everything modifying
the expiry but most of that is inlines and we don't need the bloat.

Fixes: 2d44ae4d7135 ("hrtimer: clean up cpu->base locking tricks")
Signed-off-by: Peter Zijlstra (Intel) 
Cc: Ben Segall 
Cc: Roman Gushchin 
Cc: Paul Turner 
Link: 
http://lkml.kernel.org/r/20150415113105.gt5...@twins.programming.kicks-ass.net
Signed-off-by: Thomas Gleixner 
Signed-off-by: Zefan Li 
---
 kernel/hrtimer.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
index 434f2b6..34031a0 100644
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -853,6 +853,9 @@ u64 hrtimer_forward(struct hrtimer *timer, ktime_t now, 
ktime_t interval)
if (delta.tv64 < 0)
return 0;
 
+   if (WARN_ON(timer->state & HRTIMER_STATE_ENQUEUED))
+   return 0;
+
if (interval.tv64 < timer->base->resolution.tv64)
interval.tv64 = timer->base->resolution.tv64;
 
@@ -1265,11 +1268,14 @@ static void __run_hrtimer(struct hrtimer *timer, 
ktime_t *now)
 * Note: We clear the CALLBACK bit after enqueue_hrtimer and
 * we do not reprogramm the event hardware. Happens either in
 * hrtimer_start_range_ns() or in hrtimer_interrupt()
+*
+* Note: Because we dropped the cpu_base->lock above,
+* hrtimer_start_range_ns() can have popped in and enqueued the timer
+* for us already.
 */
-   if (restart != HRTIMER_NORESTART) {
-   BUG_ON(timer->state != HRTIMER_STATE_CALLBACK);
+   if (restart != HRTIMER_NORESTART &&
+   !(timer->state & HRTIMER_STATE_ENQUEUED))
enqueue_hrtimer(timer, base);
-   }
 
WARN_ON_ONCE(!(timer->state & HRTIMER_STATE_CALLBACK));
 
-- 
1.9.1

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

[PATCH 3.4 02/65] mtd: fix: avoid race condition when accessing mtd->usecount

[lizf]

From: Brian Norris 

3.4.110-rc1 review patch.  If anyone has any objections, please let me know.

--


commit 073db4a51ee43ccb827f54a4261c0583b028d5ab upstream.

On A MIPS 32-cores machine a BUG_ON was triggered because some acesses to
mtd->usecount were done without taking mtd_table_mutex.
kernel: Call Trace:
kernel: [] __put_mtd_device+0x20/0x50
kernel: [] blktrans_release+0x8c/0xd8
kernel: [] __blkdev_put+0x1a8/0x200
kernel: [] blkdev_close+0x1c/0x30
kernel: [] __fput+0xac/0x250
kernel: [] task_work_run+0xd8/0x120
kernel: [] work_notifysig+0x10/0x18
kernel:
kernel:
Code: 2442  ac8202d8  000217fe <00020336> dc820128  1043
     0040f809  
kernel: ---[ end trace 080fbb4579b47a73 ]---

Fixed by taking the mutex in blktrans_open and blktrans_release.

Note that this locking is already suggested in
include/linux/mtd/blktrans.h:

struct mtd_blktrans_ops {
...
/* Called with mtd_table_mutex held; no race with add/remove */
int (*open)(struct mtd_blktrans_dev *dev);
void (*release)(struct mtd_blktrans_dev *dev);
...
};

But we weren't following it.

Originally reported by (and patched by) Zhang and Giuseppe,
independently. Improved and rewritten.

Reported-by: Zhang Xingcai 
Reported-by: Giuseppe Cantavenera 
Tested-by: Giuseppe Cantavenera 
Acked-by: Alexander Sverdlin 
Signed-off-by: Brian Norris 
Signed-off-by: Zefan Li 
---
 drivers/mtd/mtd_blkdevs.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/mtd/mtd_blkdevs.c b/drivers/mtd/mtd_blkdevs.c
index f1f0671..1917f7d 100644
--- a/drivers/mtd/mtd_blkdevs.c
+++ b/drivers/mtd/mtd_blkdevs.c
@@ -214,6 +214,7 @@ static int blktrans_open(struct block_device *bdev, fmode_t 
mode)
return -ERESTARTSYS; /* FIXME: busy loop! -arnd*/
 
mutex_lock(>lock);
+   mutex_lock(_table_mutex);
 
if (dev->open)
goto unlock;
@@ -237,6 +238,7 @@ static int blktrans_open(struct block_device *bdev, fmode_t 
mode)
 
 unlock:
dev->open++;
+   mutex_unlock(_table_mutex);
mutex_unlock(>lock);
blktrans_dev_put(dev);
return ret;
@@ -247,6 +249,7 @@ error_release:
 error_put:
module_put(dev->tr->owner);
kref_put(>ref, blktrans_dev_release);
+   mutex_unlock(_table_mutex);
mutex_unlock(>lock);
blktrans_dev_put(dev);
return ret;
@@ -261,6 +264,7 @@ static int blktrans_release(struct gendisk *disk, fmode_t 
mode)
return ret;
 
mutex_lock(>lock);
+   mutex_lock(_table_mutex);
 
if (--dev->open)
goto unlock;
@@ -273,6 +277,7 @@ static int blktrans_release(struct gendisk *disk, fmode_t 
mode)
__put_mtd_device(dev->mtd);
}
 unlock:
+   mutex_unlock(_table_mutex);
mutex_unlock(>lock);
blktrans_dev_put(dev);
return ret;
-- 
1.9.1

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

Re: [PATCH 3.4 00/65] 3.4.110-rc1 review

[Zefan Li]

This is the combined patch for 3.4.110-rc1 relative to 3.4.109.

---

diff --git a/Documentation/networking/pktgen.txt 
b/Documentation/networking/pktgen.txt
index 75e4fd7..a03239c 100644
--- a/Documentation/networking/pktgen.txt
+++ b/Documentation/networking/pktgen.txt
@@ -24,17 +24,33 @@ For monitoring and control pktgen creates:
 /proc/net/pktgen/ethX
 
 
-Viewing threads

-===
-/proc/net/pktgen/kpktgend_0
-Name: kpktgend_0  max_before_softirq: 1
-Running:
-Stopped: eth1
-Result: OK: max_before_softirq=1
+Kernel threads
+==
+Pktgen creates a thread for each CPU with affinity to that CPU.
+Which is controlled through procfile /proc/net/pktgen/kpktgend_X.
+
+Example: /proc/net/pktgen/kpktgend_0
+
+ Running:
+ Stopped: eth4@0
+ Result: OK: add_device=eth4@0
+
+Most important are the devices assigned to the thread.
 
-Most important the devices assigned to thread. Note! A device can only belong

-to one thread.
+The two basic thread commands are:
+ * add_device DEVICE@NAME -- adds a single device
+ * rem_device_all -- remove all associated devices
 
+When adding a device to a thread, a corrosponding procfile is created

+which is used for configuring this device. Thus, device names need to
+be unique.
+
+To support adding the same device to multiple threads, which is useful
+with multi queue NICs, a the device naming scheme is extended with "@":
+ device@something
+
+The part after "@" can be anything, but it is custom to use the thread
+number.
 
 Viewing devices

 ===
@@ -42,29 +58,32 @@ Viewing devices
 Parm section holds configured info. Current hold running stats.
 Result is printed after run or after interruption. Example:
 
-/proc/net/pktgen/eth1

+/proc/net/pktgen/eth4@0
 
-Params: count 1000  min_pkt_size: 60  max_pkt_size: 60

- frags: 0  delay: 0  clone_skb: 100  ifname: eth1
+ Params: count 10  min_pkt_size: 60  max_pkt_size: 60
+ frags: 0  delay: 0  clone_skb: 64  ifname: eth4@0
  flows: 0 flowlen: 0
- dst_min: 10.10.11.2  dst_max:
- src_min:   src_max:
- src_mac: 00:00:00:00:00:00  dst_mac: 00:04:23:AC:FD:82
- udp_src_min: 9  udp_src_max: 9  udp_dst_min: 9  udp_dst_max: 9
- src_mac_count: 0  dst_mac_count: 0
- Flags:
-Current:
- pkts-sofar: 1000  errors: 39664
- started: 1103053986245187us  stopped: 1103053999346329us idle: 880401us
- seq_num: 1011  cur_dst_mac_offset: 0  cur_src_mac_offset: 0
- cur_saddr: 0x10a0a0a  cur_daddr: 0x20b0a0a
- cur_udp_dst: 9  cur_udp_src: 9
+ queue_map_min: 0  queue_map_max: 0
+ dst_min: 192.168.81.2  dst_max:
+ src_min:   src_max:
+ src_mac: 90:e2:ba:0a:56:b4 dst_mac: 00:1b:21:3c:9d:f8
+ udp_src_min: 9  udp_src_max: 109  udp_dst_min: 9  udp_dst_max: 9
+ src_mac_count: 0  dst_mac_count: 0
+ Flags: UDPSRC_RND  NO_TIMESTAMP  QUEUE_MAP_CPU
+ Current:
+ pkts-sofar: 10  errors: 0
+ started: 623913381008us  stopped: 623913396439us idle: 25us
+ seq_num: 11  cur_dst_mac_offset: 0  cur_src_mac_offset: 0
+ cur_saddr: 192.168.8.3  cur_daddr: 192.168.81.2
+ cur_udp_dst: 9  cur_udp_src: 42
+ cur_queue_map:
  flows: 0
-Result: OK: 13101142(c12220741+d880401) usec, 1000 (60byte,0frags)
-  763292pps 390Mb/sec (390805504bps) errors: 39664
+ Result: OK: 15430(c15405d25) usec, 10 (60byte,0frags)
+  6480562pps 3110Mb/sec (3110669760bps) errors: 0
 
-Configuring threads and devices

-
+
+Configuring devices
+===
 This is done via the /proc interface easiest done via pgset in the scripts
 
 Examples:

@@ -177,6 +196,8 @@ Note when adding devices to a specific CPU there good idea 
to also assign
 /proc/irq/XX/smp_affinity so the TX-interrupts gets bound to the same CPU.
 as this reduces cache bouncing when freeing skb's.
 
+Plus using the device flag QUEUE_MAP_CPU, which maps the SKBs TX queue

+to the running threads CPU (directly from smp_processor_id()).
 
 Current commands and configuration options

 ==
diff --git a/Makefile b/Makefile
index 7337720..a4b2383 100644
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 VERSION = 3
 PATCHLEVEL = 4
-SUBLEVEL = 109
-EXTRAVERSION =
+SUBLEVEL = 110
+EXTRAVERSION = -rc1
 NAME = Saber-toothed Squirrel
 
 # *DOCUMENTATION*

diff --git a/arch/arm/net/bpf_jit_32.c b/arch/arm/net/bpf_jit_32.c
index ad94145..77026415 100644
--- a/arch/arm/net/bpf_jit_32.c
+++ b/arch/arm/net/bpf_jit_32.c
@@ -899,7 +899,7 @@ void bpf_jit_compile(struct sk_filter *fp)
if (ctx.imm_count)
kfree(ctx.imms);
 #endif
-   bpf_jit_binary_free(header);
+   module_free(NULL, ctx.target);
goto out;
}
build_epilogue();
diff --git a/arch/s390/crypto/ghash_s390.c b/arch/s390/crypto/ghash_s390.c
index c2dac2e..69b5a4b 100644
--- a/arch/s390/crypto/ghash_s390.c
+++ b/arch/s390/crypto/ghash_s390.c
@@ 

[PATCH 3.4 06/65] ASoC: wm8955: Fix setting wrong register for WM8955_K_8_0_MASK bits

[lizf]

From: Axel Lin 

3.4.110-rc1 review patch.  If anyone has any objections, please let me know.

--


commit 12c350050538c7dc779c083b7342bfd20f74949c upstream.

WM8955_K_8_0_MASK bits is controlled by WM8955_PLL_CONTROL_3 rather than
WM8955_PLL_CONTROL_2.

Signed-off-by: Axel Lin 
Acked-by: Charles Keepax 
Signed-off-by: Mark Brown 
Signed-off-by: Zefan Li 
---
 sound/soc/codecs/wm8955.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/wm8955.c b/sound/soc/codecs/wm8955.c
index 4696f66..07b78a9 100644
--- a/sound/soc/codecs/wm8955.c
+++ b/sound/soc/codecs/wm8955.c
@@ -298,7 +298,7 @@ static int wm8955_configure_clocking(struct snd_soc_codec 
*codec)
snd_soc_update_bits(codec, WM8955_PLL_CONTROL_2,
WM8955_K_17_9_MASK,
(pll.k >> 9) & WM8955_K_17_9_MASK);
-   snd_soc_update_bits(codec, WM8955_PLL_CONTROL_2,
+   snd_soc_update_bits(codec, WM8955_PLL_CONTROL_3,
WM8955_K_8_0_MASK,
pll.k & WM8955_K_8_0_MASK);
if (pll.k)
-- 
1.9.1

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

RE: [PATCH 3/3] Thermal: do thermal zone update after a cooling device registered

[Chen, Yu C]

Hi,
> -Original Message-
> From: Javi Merino [mailto:javi.mer...@arm.com]
> Sent: Thursday, October 15, 2015 10:05 PM
> To: Chen, Yu C
> Cc: linux...@vger.kernel.org; edubez...@gmail.com; Zhang, Rui; linux-
> ker...@vger.kernel.org; sta...@vger.kernel.org; Pandruvada, Srinivas
> Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a cooling
> device registered
> 
> On Wed, Oct 14, 2015 at 07:23:55PM +, Chen, Yu C wrote:
> > > -Original Message-
> > > From: Javi Merino [mailto:javi.mer...@arm.com]
> > > Sent: Thursday, October 15, 2015 1:08 AM
> > > To: Chen, Yu C
> > > Cc: linux...@vger.kernel.org; edubez...@gmail.com; Zhang, Rui;
> > > linux- ker...@vger.kernel.org; sta...@vger.kernel.org; Pandruvada,
> > > Srinivas
> > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a
> > > cooling device registered
> > >
> > > On Mon, Oct 12, 2015 at 09:23:28AM +, Chen, Yu C wrote:
> > > > Hi, Javi
> > > > Sorry for my late response,
> > > >
> > > > > -Original Message-
> > > > > From: Javi Merino [mailto:javi.mer...@arm.com]
> > > > > Sent: Wednesday, September 30, 2015 12:02 AM
> > > > > To: Chen, Yu C
> > > > > Cc: linux...@vger.kernel.org; edubez...@gmail.com; Zhang, Rui;
> > > > > linux- ker...@vger.kernel.org; sta...@vger.kernel.org
> > > > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update after a
> > > > > cooling device registered
> > > > >
> > > > > Hi Yu,
> > > > >
> > > > > On Mon, Sep 28, 2015 at 06:52:00PM +0100, Chen, Yu C wrote:
> > > > > > Hi, Javi,
> > > > > >
> > > > > > > -Original Message-
> > > > > > > From: Javi Merino [mailto:javi.mer...@arm.com]
> > > > > > > Sent: Monday, September 28, 2015 10:29 PM
> > > > > > > To: Chen, Yu C
> > > > > > > Cc: linux...@vger.kernel.org; edubez...@gmail.com; Zhang,
> > > > > > > Rui;
> > > > > > > linux- ker...@vger.kernel.org; sta...@vger.kernel.org
> > > > > > > Subject: Re: [PATCH 3/3] Thermal: do thermal zone update
> > > > > > > after a cooling device registered
> > > > > > >
> > > > > > > On Sun, Sep 27, 2015 at 06:48:44AM +0100, Chen Yu wrote:
> > > > > > > > From: Zhang Rui 
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > I think you need to hold cdev->lock here, to make sure that
> > > > > > > no thermal zone is added or removed from
> > > > > > > cdev->thermal_instances while
> > > > > you are looping.
> > > > > > >
> > > > > > Ah right, will add. If I add the cdev ->lock here, will there
> > > > > > be a AB-BA lock with thermal_zone_unbind_cooling_device?
> > > > >
> > > > > You're right, it could lead to a deadlock.  The locks can't be
> > > > > swapped because that won't work in step_wise.
> > > > >
> > > > > The best way that I can think of accessing thermal_instances
> > > > > atomically is by making it RCU protected instead of with mutexes.
> > > > > What do you think?
> > > > >
> > > > RCU would need extra spinlocks to protect the list, and need to
> > > > sync_rcu after we delete one instance from thermal_instance list,
> > > > I think it is too complicated for me to rewrite: ( How about using
> > > thermal_list_lock instead of cdev ->lock?
> > > > This guy should be big enough to protect the device.thermal_instance
> list.
> > >
> > > thermal_list_lock protects thermal_tz_list and thermal_cdev_list,
> > > but it doesn't protect the thermal_instances list.  For example,
> > > thermal_zone_bind_cooling_device() adds a cooling device to the
> > > cdev->thermal_instances list without taking thermal_tz_list.
> > >
> > Before thermal_zone_bind_cooling_device is invoked, the
> > thermal_list_lock will be firstly gripped:
> >
> > static void bind_cdev(struct thermal_cooling_device *cdev) {
> > mutex_lock(_list_lock);
> > either tz->ops->bind:   thermal_zone_bind_cooling_device
> > or __bind()  :   thermal_zone_bind_cooling_device
> > mutex_unlock(_list_lock);
> > }
> >
> > And it is the same as in  passive_store.
> > So when code is trying to add/delete thermal_instance of cdev, he has
> > already hold thermal_list_lock IMO. Or do I miss anything?
> 
> thermal_zone_bind_cooling_device() is exported, so you can't really rely on
> the static thermal_list_lock being acquired in every single call.
> 
> thermal_list_lock and protects the lists thermal_tz_list and 
> thermal_cdev_list.
> Making it implicitly protect the cooling device's and thermal zone device's
> instances list because no sensible code would call
> thermal_zone_bind_cooling_device() outside of a bind function is just asking
> for trouble.
> 
Yes, from this point of view,it is true. 

> Locking is hard to understand and easy to get wrong so let's keep it simple.
> 
How about the following 2 methods:
1. avoid accessing device's thermal_instance,but
access all thermal_zone_device directly, although there might be some 
redundancy,
some thermal zones do not need to be updated, but we can avoid gripping 
dev->lock:

mutex_lock(_list_lock);
list_for_each_entry(pos, _tz_list, node)

[PATCH 3.4 09/65] tty/serial: at91: RS485 mode: 0 is valid for delay_rts_after_send

[lizf]

From: Nicolas Ferre 

3.4.110-rc1 review patch.  If anyone has any objections, please let me know.

--


commit 8687634b7908c42eb700e0469e110e02833611d1 upstream.

In RS485 mode, we may want to set the delay_rts_after_send value to 0.
In the datasheet, the 0 value is said to "disable" the Transmitter Timeguard but
this is exactly the expected behavior if we want no delay...

Moreover, if the value was set to non-zero value by device-tree or earlier
ioctl command, it was impossible to change it back to zero.

Reported-by: Sami Pietikäinen 
Signed-off-by: Nicolas Ferre 
Signed-off-by: Greg Kroah-Hartman 
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li 
---
 drivers/tty/serial/atmel_serial.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/tty/serial/atmel_serial.c 
b/drivers/tty/serial/atmel_serial.c
index ff58d28..85c28e3 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -229,8 +229,7 @@ void atmel_config_rs485(struct uart_port *port, struct 
serial_rs485 *rs485conf)
if (rs485conf->flags & SER_RS485_ENABLED) {
dev_dbg(port->dev, "Setting UART to RS485\n");
atmel_port->tx_done_mask = ATMEL_US_TXEMPTY;
-   if ((rs485conf->delay_rts_after_send) > 0)
-   UART_PUT_TTGR(port, rs485conf->delay_rts_after_send);
+   UART_PUT_TTGR(port, rs485conf->delay_rts_after_send);
mode |= ATMEL_US_USMODE_RS485;
} else {
dev_dbg(port->dev, "Setting UART to RS232\n");
@@ -305,9 +304,7 @@ static void atmel_set_mctrl(struct uart_port *port, u_int 
mctrl)
 
if (atmel_port->rs485.flags & SER_RS485_ENABLED) {
dev_dbg(port->dev, "Setting UART to RS485\n");
-   if ((atmel_port->rs485.delay_rts_after_send) > 0)
-   UART_PUT_TTGR(port,
-   atmel_port->rs485.delay_rts_after_send);
+   UART_PUT_TTGR(port, atmel_port->rs485.delay_rts_after_send);
mode |= ATMEL_US_USMODE_RS485;
} else {
dev_dbg(port->dev, "Setting UART to RS232\n");
@@ -1239,9 +1236,7 @@ static void atmel_set_termios(struct uart_port *port, 
struct ktermios *termios,
 
if (atmel_port->rs485.flags & SER_RS485_ENABLED) {
dev_dbg(port->dev, "Setting UART to RS485\n");
-   if ((atmel_port->rs485.delay_rts_after_send) > 0)
-   UART_PUT_TTGR(port,
-   atmel_port->rs485.delay_rts_after_send);
+   UART_PUT_TTGR(port, atmel_port->rs485.delay_rts_after_send);
mode |= ATMEL_US_USMODE_RS485;
} else {
dev_dbg(port->dev, "Setting UART to RS232\n");
-- 
1.9.1

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

[PATCH 3.4 10/65] rndis_wlan: harmless issue calling set_bit()

[lizf]

From: Dan Carpenter 

3.4.110-rc1 review patch.  If anyone has any objections, please let me know.

--


commit e3958e9d60b4570fff709f397ef5c6b8483f40f7 upstream.

These are used like:

set_bit(WORK_LINK_UP, >work_pending);

The problem is that set_bit() takes the actual bit number and not a mask
so static checkers get upset.  It doesn't affect run time because we do
it consistently, but we may as well clean it up.

Fixes: 6010ce07a66c ('rndis_wlan: do link-down state change in worker thread')
Signed-off-by: Dan Carpenter 
Signed-off-by: Kalle Valo 
Signed-off-by: Zefan Li 
---
 drivers/net/wireless/rndis_wlan.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/net/wireless/rndis_wlan.c 
b/drivers/net/wireless/rndis_wlan.c
index d66e298..414ac49 100644
--- a/drivers/net/wireless/rndis_wlan.c
+++ b/drivers/net/wireless/rndis_wlan.c
@@ -407,9 +407,9 @@ struct ndis_80211_pmkid {
 #define CAP_MODE_80211G4
 #define CAP_MODE_MASK  7
 
-#define WORK_LINK_UP   (1<<0)
-#define WORK_LINK_DOWN (1<<1)
-#define WORK_SET_MULTICAST_LIST(1<<2)
+#define WORK_LINK_UP   0
+#define WORK_LINK_DOWN 1
+#define WORK_SET_MULTICAST_LIST2
 
 #define RNDIS_WLAN_ALG_NONE0
 #define RNDIS_WLAN_ALG_WEP (1<<0)
-- 
1.9.1

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

[PATCH 3.4 15/65] staging: rtl8712: prevent buffer overrun in recvbuf2recvframe

[lizf]

From: Haggai Eran 

3.4.110-rc1 review patch.  If anyone has any objections, please let me know.

--


commit cab462140f8a183e3cca0b51c8b59ef715cb6148 upstream.

With an RTL8191SU USB adaptor, sometimes the hints for a fragmented
packet are set, but the packet length is too large. Allocate enough
space to prevent memory corruption and a resulting kernel panic [1].

[1] http://www.spinics.net/lists/linux-wireless/msg136546.html

Signed-off-by: Haggai Eran 
ACKed-by: Larry Finger 
Signed-off-by: Greg Kroah-Hartman 
Signed-off-by: Zefan Li 
---
 drivers/staging/rtl8712/rtl8712_recv.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8712/rtl8712_recv.c 
b/drivers/staging/rtl8712/rtl8712_recv.c
index 887a807..549b8ab 100644
--- a/drivers/staging/rtl8712/rtl8712_recv.c
+++ b/drivers/staging/rtl8712/rtl8712_recv.c
@@ -1074,7 +1074,8 @@ static int recvbuf2recvframe(struct _adapter *padapter, 
struct sk_buff *pskb)
/* for first fragment packet, driver need allocate 1536 +
 * drvinfo_sz + RXDESC_SIZE to defrag packet. */
if ((mf == 1) && (frag == 0))
-   alloc_sz = 1658;/*1658+6=1664, 1664 is 128 alignment.*/
+   /*1658+6=1664, 1664 is 128 alignment.*/
+   alloc_sz = max_t(u16, tmp_len, 1658);
else
alloc_sz = tmp_len;
/* 2 is for IP header 4 bytes alignment in QoS packet case.
-- 
1.9.1

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

Re: [PATCH] devfreq: correctly check failed allocation

[MyungJoo Ham]

>Since devm_kzalloc can be failed in memory pressure,
>check return value and handle error.
>
>Signed-off-by: Insu Yun 
>---
> drivers/devfreq/devfreq.c | 14 ++
> 1 file changed, 14 insertions(+)
>
>diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
>index ca1b362..814089f 100644
>--- a/drivers/devfreq/devfreq.c
>+++ b/drivers/devfreq/devfreq.c
>@@ -482,9 +482,23 @@ struct devfreq *devfreq_add_device(struct device *dev,
>   devfreq->profile->max_state *
>   devfreq->profile->max_state,
>   GFP_KERNEL);
>+  if (!devfreq->trans_table) {
>+  dev_err(dev, "%s: Unable to create transition table for the 
>device\n",
>+  __func__);
>+  err = -ENOMEM;
>+  goto err_dev;
>+  }
>+

I don't see a label 'err_dev' in devfreq.c
And please note that you are under a mutex lock here as well; you must unlock 
it before returning.


For devfreq.c of most recent release candidate, please refer to 
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/devfreq/devfreq.c?id=7379047d5585187d1288486d4627873170d0005a

You don't seem to be based on a recent RC as well.

Cheers,
MyungJoo

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

[PATCH 3.4 19/65] SUNRPC: Fix a memory leak in the backchannel code

[lizf]

From: Trond Myklebust 

3.4.110-rc1 review patch.  If anyone has any objections, please let me know.

--


commit 88de6af24f2b48b06c514d3c3d0a8f22fafe30bd upstream.

req->rq_private_buf isn't initialised when xprt_setup_backchannel calls
xprt_free_allocation.

Fixes: fb7a0b9addbdb ("nfs41: New backchannel helper routines")
Signed-off-by: Trond Myklebust 
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li 
---
 net/sunrpc/backchannel_rqst.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/sunrpc/backchannel_rqst.c b/net/sunrpc/backchannel_rqst.c
index 31def68..617b955 100644
--- a/net/sunrpc/backchannel_rqst.c
+++ b/net/sunrpc/backchannel_rqst.c
@@ -60,7 +60,7 @@ static void xprt_free_allocation(struct rpc_rqst *req)
 
dprintk("RPC:free allocations for req= %p\n", req);
BUG_ON(test_bit(RPC_BC_PA_IN_USE, >rq_bc_pa_state));
-   xbufp = >rq_private_buf;
+   xbufp = >rq_rcv_buf;
free_page((unsigned long)xbufp->head[0].iov_base);
xbufp = >rq_snd_buf;
free_page((unsigned long)xbufp->head[0].iov_base);
-- 
1.9.1

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

[PATCH 3.4 16/65] usb: core: Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset

[lizf]

From: Robert Schlabbach 

3.4.110-rc1 review patch.  If anyone has any objections, please let me know.

--


commit fb6d1f7df5d25299fd7b3e84b72b8851d3634764 upstream.

Fix USB 3.0 devices lost in NOTATTACHED state after a hub port reset.

Dissolve the function hub_port_finish_reset() completely and divide the
actions to be taken into those which need to be done after each reset
attempt and those which need to be done after the full procedure is
complete, and place them in the appropriate places in hub_port_reset().
Also, remove an unneeded forward declaration of hub_port_reset().

Verbose Problem Description:

USB 3.0 devices may be "lost for good" during a hub port reset.
This makes Linux unable to boot from USB 3.0 devices in certain
constellations of host controllers and devices, because the USB device is
lost during initialization, preventing the rootfs from being mounted.

The underlying problem is that in the affected constellations, during the
processing inside hub_port_reset(), the hub link state goes from 0 to
SS.inactive after the initial reset, and back to 0 again only after the
following "warm" reset.

However, hub_port_finish_reset() is called after each reset attempt and
sets the state the connected USB device based on the "preliminary" status
of the hot reset to USB_STATE_NOTATTACHED due to SS.inactive, yet when
the following warm reset is complete and hub_port_finish_reset() is
called again, its call to set the device to USB_STATE_DEFAULT is blocked
by usb_set_device_state() which does not allow taking USB devices out of
USB_STATE_NOTATTACHED state.

Thanks to Alan Stern for guiding me to the proper solution and how to
submit it.

Link: 
http://lkml.kernel.org/r/trinity-25981484-72a9-4d46-bf17-9c1cf9301a31-1432073240136%20()%203capp-gmx-bs27
Signed-off-by: Robert Schlabbach 
Acked-by: Alan Stern 
Signed-off-by: Greg Kroah-Hartman 
[lizf: Backported to 3.4:
 - adjust context
 - s/usb_clear_port_feature/clear_port_feature
 - hub_port_warm_reset_required() takes only two arguments]
Signed-off-by: Zefan Li 
---
 drivers/usb/core/hub.c | 81 --
 1 file changed, 32 insertions(+), 49 deletions(-)

diff --git a/drivers/usb/core/hub.c b/drivers/usb/core/hub.c
index 93f2538..62ea924 100644
--- a/drivers/usb/core/hub.c
+++ b/drivers/usb/core/hub.c
@@ -2176,9 +2176,6 @@ static unsigned hub_is_wusb(struct usb_hub *hub)
 #define HUB_LONG_RESET_TIME200
 #define HUB_RESET_TIMEOUT  800
 
-static int hub_port_reset(struct usb_hub *hub, int port1,
-   struct usb_device *udev, unsigned int delay, bool warm);
-
 /* Is a USB 3.0 port in the Inactive or Complinance Mode state?
  * Port worm reset is required to recover
  */
@@ -2258,44 +2255,6 @@ delay:
return -EBUSY;
 }
 
-static void hub_port_finish_reset(struct usb_hub *hub, int port1,
-   struct usb_device *udev, int *status)
-{
-   switch (*status) {
-   case 0:
-   /* TRSTRCY = 10 ms; plus some extra */
-   msleep(10 + 40);
-   if (udev) {
-   struct usb_hcd *hcd = bus_to_hcd(udev->bus);
-
-   update_devnum(udev, 0);
-   /* The xHC may think the device is already reset,
-* so ignore the status.
-*/
-   if (hcd->driver->reset_device)
-   hcd->driver->reset_device(hcd, udev);
-   }
-   /* FALL THROUGH */
-   case -ENOTCONN:
-   case -ENODEV:
-   clear_port_feature(hub->hdev,
-   port1, USB_PORT_FEAT_C_RESET);
-   if (hub_is_superspeed(hub->hdev)) {
-   clear_port_feature(hub->hdev, port1,
-   USB_PORT_FEAT_C_BH_PORT_RESET);
-   clear_port_feature(hub->hdev, port1,
-   USB_PORT_FEAT_C_PORT_LINK_STATE);
-   clear_port_feature(hub->hdev, port1,
-   USB_PORT_FEAT_C_CONNECTION);
-   }
-   if (udev)
-   usb_set_device_state(udev, *status
-   ? USB_STATE_NOTATTACHED
-   : USB_STATE_DEFAULT);
-   break;
-   }
-}
-
 /* Handle port reset and port warm(BH) reset (for USB3 protocol ports) */
 static int hub_port_reset(struct usb_hub *hub, int port1,
struct usb_device *udev, unsigned int delay, bool warm)
@@ -2318,13 +2277,9 @@ static int hub_port_reset(struct usb_hub *hub, int port1,
 * If the caller hasn't explicitly requested a warm reset,
 * double check and see if one is needed.
 */
-   status = hub_port_status(hub, port1,
-   , );
-   if (status 

[PATCH 3.4 20/65] ipr: Increase default adapter init stage change timeout

[lizf]

From: Brian King 

3.4.110-rc1 review patch.  If anyone has any objections, please let me know.

--


commit 45c44b5ff9caa743ed9c2bfd44307c536c9caf1e upstream.

Increase the default init stage change timeout from 15 seconds to 30 seconds.
This resolves issues we have seen with some adapters not transitioning
to the first init stage within 15 seconds, which results in adapter
initialization failures.

Signed-off-by: Brian King 
Signed-off-by: James Bottomley 
Signed-off-by: Zefan Li 
---
 drivers/scsi/ipr.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/ipr.h b/drivers/scsi/ipr.h
index 153b8bd..19ff8b2 100644
--- a/drivers/scsi/ipr.h
+++ b/drivers/scsi/ipr.h
@@ -251,7 +251,7 @@
 #define IPR_RUNTIME_RESET  0x4000
 
 #define IPR_IPL_INIT_MIN_STAGE_TIME5
-#define IPR_IPL_INIT_DEFAULT_STAGE_TIME 15
+#define IPR_IPL_INIT_DEFAULT_STAGE_TIME 30
 #define IPR_IPL_INIT_STAGE_UNKNOWN 0x0
 #define IPR_IPL_INIT_STAGE_TRANSOP 0xB000
 #define IPR_IPL_INIT_STAGE_MASK0xff00
-- 
1.9.1

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

[PATCH 3.4 29/65] sctp: fix ASCONF list handling

[lizf]

From: Marcelo Ricardo Leitner 

3.4.110-rc1 review patch.  If anyone has any objections, please let me know.

--


commit 2d45a02d0166caf2627fe91897c6ffc3b19514c4 upstream.

->auto_asconf_splist is per namespace and mangled by functions like
sctp_setsockopt_auto_asconf() which doesn't guarantee any serialization.

Also, the call to inet_sk_copy_descendant() was backuping
->auto_asconf_list through the copy but was not honoring
->do_auto_asconf, which could lead to list corruption if it was
different between both sockets.

This commit thus fixes the list handling by using ->addr_wq_lock
spinlock to protect the list. A special handling is done upon socket
creation and destruction for that. Error handlig on sctp_init_sock()
will never return an error after having initialized asconf, so
sctp_destroy_sock() can be called without addrq_wq_lock. The lock now
will be take on sctp_close_sock(), before locking the socket, so we
don't do it in inverse order compared to sctp_addr_wq_timeout_handler().

Instead of taking the lock on sctp_sock_migrate() for copying and
restoring the list values, it's preferred to avoid rewritting it by
implementing sctp_copy_descendant().

Issue was found with a test application that kept flipping sysctl
default_auto_asconf on and off, but one could trigger it by issuing
simultaneous setsockopt() calls on multiple sockets or by
creating/destroying sockets fast enough. This is only triggerable
locally.

Fixes: 9f7d653b67ae ("sctp: Add Auto-ASCONF support (core).")
Reported-by: Ji Jianwen 
Suggested-by: Neil Horman 
Suggested-by: Hannes Frederic Sowa 
Acked-by: Hannes Frederic Sowa 
Signed-off-by: Marcelo Ricardo Leitner 
Signed-off-by: David S. Miller 
[lizf: Backported to 3.4:
 - use global spinlock instead of per-namespace lock]
Signed-off-by: Zefan Li 
---
 include/net/sctp/structs.h |  5 +
 net/sctp/socket.c  | 43 ---
 2 files changed, 37 insertions(+), 11 deletions(-)

diff --git a/include/net/sctp/structs.h b/include/net/sctp/structs.h
index 88949a9..4ea0ec6 100644
--- a/include/net/sctp/structs.h
+++ b/include/net/sctp/structs.h
@@ -209,6 +209,7 @@ extern struct sctp_globals {
struct list_head addr_waitq;
struct timer_list addr_wq_timer;
struct list_head auto_asconf_splist;
+   /* Lock that protects both addr_waitq and auto_asconf_splist */
spinlock_t addr_wq_lock;
 
/* Lock that protects the local_addr_list writers */
@@ -355,6 +356,10 @@ struct sctp_sock {
atomic_t pd_mode;
/* Receive to here while partial delivery is in effect. */
struct sk_buff_head pd_lobby;
+
+   /* These must be the last fields, as they will skipped on copies,
+* like on accept and peeloff operations
+*/
struct list_head auto_asconf_list;
int do_auto_asconf;
 };
diff --git a/net/sctp/socket.c b/net/sctp/socket.c
index 0c0bd2f..bc7b5de 100644
--- a/net/sctp/socket.c
+++ b/net/sctp/socket.c
@@ -1539,8 +1539,10 @@ SCTP_STATIC void sctp_close(struct sock *sk, long 
timeout)
 
/* Supposedly, no process has access to the socket, but
 * the net layers still may.
+* Also, sctp_destroy_sock() needs to be called with addr_wq_lock
+* held and that should be grabbed before socket lock.
 */
-   sctp_local_bh_disable();
+   spin_lock_bh(_globals.addr_wq_lock);
sctp_bh_lock_sock(sk);
 
/* Hold the sock, since sk_common_release() will put sock_put()
@@ -1550,7 +1552,7 @@ SCTP_STATIC void sctp_close(struct sock *sk, long timeout)
sk_common_release(sk);
 
sctp_bh_unlock_sock(sk);
-   sctp_local_bh_enable();
+   spin_unlock_bh(_globals.addr_wq_lock);
 
sock_put(sk);
 
@@ -3492,6 +3494,7 @@ static int sctp_setsockopt_auto_asconf(struct sock *sk, 
char __user *optval,
if ((val && sp->do_auto_asconf) || (!val && !sp->do_auto_asconf))
return 0;
 
+   spin_lock_bh(_globals.addr_wq_lock);
if (val == 0 && sp->do_auto_asconf) {
list_del(>auto_asconf_list);
sp->do_auto_asconf = 0;
@@ -3500,6 +3503,7 @@ static int sctp_setsockopt_auto_asconf(struct sock *sk, 
char __user *optval,
_auto_asconf_splist);
sp->do_auto_asconf = 1;
}
+   spin_unlock_bh(_globals.addr_wq_lock);
return 0;
 }
 
@@ -3935,18 +3939,28 @@ SCTP_STATIC int sctp_init_sock(struct sock *sk)
local_bh_disable();
percpu_counter_inc(_sockets_allocated);
sock_prot_inuse_add(sock_net(sk), sk->sk_prot, 1);
+
+   /* Nothing can fail after this block, otherwise
+* sctp_destroy_sock() will be called without addr_wq_lock held
+*/
if (sctp_default_auto_asconf) {
+   spin_lock(_globals.addr_wq_lock);
list_add_tail(>auto_asconf_list,
_auto_asconf_splist);
sp->do_auto_asconf = 1;
-   

[PATCH 3.4 28/65] Disable write buffering on Toshiba ToPIC95

[lizf]

From: Ryan Underwood 

3.4.110-rc1 review patch.  If anyone has any objections, please let me know.

--


commit 2fb22a8042fe96b4220843f79241c116d90922c4 upstream.

Disable write buffering on the Toshiba ToPIC95 if it is enabled by
somebody (it is not supposed to be a power-on default according to
the datasheet). On the ToPIC95, practically no 32-bit Cardbus card
will work under heavy load without locking up the whole system if
this is left enabled. I tried about a dozen. It does not affect
16-bit cards. This is similar to the O2 bugs in early controller
revisions it seems.

Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=55961
Signed-off-by: Ryan C. Underwood 
Signed-off-by: Dominik Brodowski 
Signed-off-by: Zefan Li 
---
 drivers/pcmcia/topic.h | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/pcmcia/topic.h b/drivers/pcmcia/topic.h
index 615a45a..582688fe 100644
--- a/drivers/pcmcia/topic.h
+++ b/drivers/pcmcia/topic.h
@@ -104,6 +104,9 @@
 #define TOPIC_EXCA_IF_CONTROL  0x3e/* 8 bit */
 #define TOPIC_EXCA_IFC_33V_ENA 0x01
 
+#define TOPIC_PCI_CFG_PPBCN0x3e/* 16-bit */
+#define TOPIC_PCI_CFG_PPBCN_WBEN   0x0400
+
 static void topic97_zoom_video(struct pcmcia_socket *sock, int onoff)
 {
struct yenta_socket *socket = container_of(sock, struct yenta_socket, 
socket);
@@ -138,6 +141,7 @@ static int topic97_override(struct yenta_socket *socket)
 static int topic95_override(struct yenta_socket *socket)
 {
u8 fctrl;
+   u16 ppbcn;
 
/* enable 3.3V support for 16bit cards */
fctrl = exca_readb(socket, TOPIC_EXCA_IF_CONTROL);
@@ -146,6 +150,18 @@ static int topic95_override(struct yenta_socket *socket)
/* tell yenta to use exca registers to power 16bit cards */
socket->flags |= YENTA_16BIT_POWER_EXCA | YENTA_16BIT_POWER_DF;
 
+   /* Disable write buffers to prevent lockups under load with numerous
+  Cardbus cards, observed on Tecra 500CDT and reported elsewhere on the
+  net.  This is not a power-on default according to the datasheet
+  but some BIOSes seem to set it. */
+   if (pci_read_config_word(socket->dev, TOPIC_PCI_CFG_PPBCN, ) == 0
+   && socket->dev->revision <= 7
+   && (ppbcn & TOPIC_PCI_CFG_PPBCN_WBEN)) {
+   ppbcn &= ~TOPIC_PCI_CFG_PPBCN_WBEN;
+   pci_write_config_word(socket->dev, TOPIC_PCI_CFG_PPBCN, ppbcn);
+   dev_info(>dev->dev, "Disabled ToPIC95 Cardbus write 
buffers.\n");
+   }
+
return 0;
 }
 
-- 
1.9.1

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

[PATCH 3.4 23/65] regulator: core: fix constraints output buffer

[lizf]

From: Stefan Wahren 

3.4.110-rc1 review patch.  If anyone has any objections, please let me know.

--


commit a7068e3932eee8268c4ce4e080a338ee7b8a27bf upstream.

The buffer for condtraints debug isn't big enough to hold the output
in all cases. So fix this issue by increasing the buffer.

Signed-off-by: Stefan Wahren 
Signed-off-by: Mark Brown 
Signed-off-by: Zefan Li 
---
 drivers/regulator/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
index 0d71557..c8f160d 100644
--- a/drivers/regulator/core.c
+++ b/drivers/regulator/core.c
@@ -749,7 +749,7 @@ static int suspend_prepare(struct regulator_dev *rdev, 
suspend_state_t state)
 static void print_constraints(struct regulator_dev *rdev)
 {
struct regulation_constraints *constraints = rdev->constraints;
-   char buf[80] = "";
+   char buf[160] = "";
int count = 0;
int ret;
 
-- 
1.9.1

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

[PATCH 3.4 26/65] ASoC: wm8960: the enum of "DAC Polarity" should be wm8960_enum[1]

[lizf]

From: Zidan Wang 

3.4.110-rc1 review patch.  If anyone has any objections, please let me know.

--


commit a077e81ec61e07a7f86997d045109f06719fbffe upstream.

the enum of "DAC Polarity" should be wm8960_enum[1].

Signed-off-by: Zidan Wang 
Acked-by: Charles Keepax 
Signed-off-by: Mark Brown 
Signed-off-by: Zefan Li 
---
 sound/soc/codecs/wm8960.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/sound/soc/codecs/wm8960.c b/sound/soc/codecs/wm8960.c
index ed986e6..bd3c6ef 100644
--- a/sound/soc/codecs/wm8960.c
+++ b/sound/soc/codecs/wm8960.c
@@ -183,7 +183,7 @@ SOC_SINGLE("PCM Playback -6dB Switch", WM8960_DACCTL1, 7, 
1, 0),
 SOC_ENUM("ADC Polarity", wm8960_enum[0]),
 SOC_SINGLE("ADC High Pass Filter Switch", WM8960_DACCTL1, 0, 1, 0),
 
-SOC_ENUM("DAC Polarity", wm8960_enum[2]),
+SOC_ENUM("DAC Polarity", wm8960_enum[1]),
 SOC_SINGLE_BOOL_EXT("DAC Deemphasis Switch", 0,
wm8960_get_deemph, wm8960_put_deemph),
 
-- 
1.9.1

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

[PATCH 3.4 22/65] ath9k: fix DMA stop sequence for AR9003+

[lizf]

From: Felix Fietkau 

3.4.110-rc1 review patch.  If anyone has any objections, please let me know.

--


commit 300f77c08ded96d33f492aaa02549103852f0c12 upstream.

AR93xx and newer needs to stop rx before tx to avoid getting the DMA
engine or MAC into a stuck state.
This should reduce/fix the occurence of "Failed to stop Tx DMA" logspam.

Signed-off-by: Felix Fietkau 
Signed-off-by: Kalle Valo 
[lizf: Backported to 3.4:
 - initialize ret
 - ath_drain_all_txq() takes a second argument]
Signed-off-by: Zefan Li 
---
 drivers/net/wireless/ath/ath9k/main.c | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/drivers/net/wireless/ath/ath9k/main.c 
b/drivers/net/wireless/ath/ath9k/main.c
index ef26056..7e7bd15 100644
--- a/drivers/net/wireless/ath/ath9k/main.c
+++ b/drivers/net/wireless/ath/ath9k/main.c
@@ -235,7 +235,7 @@ static bool ath_prepare_reset(struct ath_softc *sc, bool 
retry_tx, bool flush)
 {
struct ath_hw *ah = sc->sc_ah;
struct ath_common *common = ath9k_hw_common(ah);
-   bool ret;
+   bool ret = true;
 
ieee80211_stop_queues(sc->hw);
 
@@ -245,10 +245,13 @@ static bool ath_prepare_reset(struct ath_softc *sc, bool 
retry_tx, bool flush)
ath9k_debug_samp_bb_mac(sc);
ath9k_hw_disable_interrupts(ah);
 
-   ret = ath_drain_all_txq(sc, retry_tx);
-
-   if (!ath_stoprecv(sc))
-   ret = false;
+   if (AR_SREV_9300_20_OR_LATER(ah)) {
+   ret &= ath_stoprecv(sc);
+   ret &= ath_drain_all_txq(sc, retry_tx);
+   } else {
+   ret &= ath_drain_all_txq(sc, retry_tx);
+   ret &= ath_stoprecv(sc);
+   }
 
if (!flush) {
if (ah->caps.hw_caps & ATH9K_HW_CAP_EDMA)
-- 
1.9.1

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

[PATCH 3.4 33/65] ideapad: fix software rfkill setting

[lizf]

From: Arnd Bergmann 

3.4.110-rc1 review patch.  If anyone has any objections, please let me know.

--


commit 4b200b4604bec3388426159f1656109d19fadf6e upstream.

This fixes a several year old regression that I found while trying
to get the Yoga 3 11 to work. The ideapad_rfk_set function is meant
to send a command to the embedded controller through ACPI, but
as of c1f73658ed, it sends the index of the rfkill device instead
of the command, and ignores the opcode field.

This changes it back to the original behavior, which indeed
flips the rfkill state as seen in the debugfs interface.

Signed-off-by: Arnd Bergmann 
Fixes: c1f73658ed ("ideapad: pass ideapad_priv as argument (part 2)")
Signed-off-by: Darren Hart 
[lizf: Backported to 3.4: @data is not a pointer but the device idx]
Signed-off-by: Zefan Li 
---
 drivers/platform/x86/ideapad-laptop.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/platform/x86/ideapad-laptop.c 
b/drivers/platform/x86/ideapad-laptop.c
index ac902f7..34e9fcf 100644
--- a/drivers/platform/x86/ideapad-laptop.c
+++ b/drivers/platform/x86/ideapad-laptop.c
@@ -407,7 +407,8 @@ const struct ideapad_rfk_data ideapad_rfk_data[] = {
 
 static int ideapad_rfk_set(void *data, bool blocked)
 {
-   unsigned long opcode = (unsigned long)data;
+   unsigned long dev = (unsigned long)data;
+   int opcode = ideapad_rfk_data[dev].opcode;
 
return write_ec_cmd(ideapad_handle, opcode, !blocked);
 }
-- 
1.9.1

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

[PATCH 3.4 31/65] regmap: Fix regmap_bulk_read in BE mode

[lizf]

From: Arun Chandran 

3.4.110-rc1 review patch.  If anyone has any objections, please let me know.

--


commit 15b8d2c41fe5839582029f65c5f7004db451cc2b upstream.

In big endian mode regmap_bulk_read gives incorrect data
for byte reads.

This is because memcpy of a single byte from an address
after full word read gives different results when
endianness differs. ie. we get little-end in LE and big-end in BE.

Signed-off-by: Arun Chandran 
Signed-off-by: Mark Brown 
[lizf: Backported to 3.4: format_val() takes only two arguments]
Signed-off-by: Zefan Li 
---
 drivers/base/regmap/regmap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 8e81f85..0ac67ac 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -784,7 +784,7 @@ int regmap_bulk_read(struct regmap *map, unsigned int reg, 
void *val,
ret = regmap_read(map, reg + i, );
if (ret != 0)
return ret;
-   memcpy(val + (i * val_bytes), , val_bytes);
+   map->format.format_val(val + (i * val_bytes), ival);
}
}
 
-- 
1.9.1

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

[PATCH 3.4 32/65] jbd2: fix ocfs2 corrupt when updating journal superblock fails

[lizf]

From: Joseph Qi 

3.4.110-rc1 review patch.  If anyone has any objections, please let me know.

--


commit 6f6a6fda294506dfe0e3e0a253bb2d2923f28f0a upstream.

If updating journal superblock fails after journal data has been
flushed, the error is omitted and this will mislead the caller as a
normal case.  In ocfs2, the checkpoint will be treated successfully
and the other node can get the lock to update. Since the sb_start is
still pointing to the old log block, it will rewrite the journal data
during journal recovery by the other node. Thus the new updates will
be overwritten and ocfs2 corrupts.  So in above case we have to return
the error, and ocfs2_commit_cache will take care of the error and
prevent the other node to do update first.  And only after recovering
journal it can do the new updates.

The issue discussion mail can be found at:
https://oss.oracle.com/pipermail/ocfs2-devel/2015-June/010856.html
http://comments.gmane.org/gmane.comp.file-systems.ext4/48841

[ Fixed bug in patch which allowed a non-negative error return from
  jbd2_cleanup_journal_tail() to leak out of jbd2_fjournal_flush(); this
  was causing xfstests ext4/306 to fail. -- Ted ]

Reported-by: Yiwen Jiang 
Signed-off-by: Joseph Qi 
Signed-off-by: Theodore Ts'o 
Tested-by: Yiwen Jiang 
Cc: Junxiao Bi 
Signed-off-by: Zefan Li 
---
 fs/jbd2/checkpoint.c |  5 ++---
 fs/jbd2/journal.c| 38 +++---
 include/linux/jbd2.h |  4 ++--
 3 files changed, 35 insertions(+), 12 deletions(-)

diff --git a/fs/jbd2/checkpoint.c b/fs/jbd2/checkpoint.c
index dadfedb..6bb5285 100644
--- a/fs/jbd2/checkpoint.c
+++ b/fs/jbd2/checkpoint.c
@@ -440,7 +440,7 @@ int jbd2_cleanup_journal_tail(journal_t *journal)
unsigned long   blocknr;
 
if (is_journal_aborted(journal))
-   return 1;
+   return -EIO;
 
if (!jbd2_journal_get_log_tail(journal, _tid, ))
return 1;
@@ -457,8 +457,7 @@ int jbd2_cleanup_journal_tail(journal_t *journal)
if (journal->j_flags & JBD2_BARRIER)
blkdev_issue_flush(journal->j_fs_dev, GFP_NOFS, NULL);
 
-   __jbd2_update_log_tail(journal, first_tid, blocknr);
-   return 0;
+   return __jbd2_update_log_tail(journal, first_tid, blocknr);
 }
 
 
diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
index f697468..ad64b94 100644
--- a/fs/jbd2/journal.c
+++ b/fs/jbd2/journal.c
@@ -823,9 +823,10 @@ int jbd2_journal_get_log_tail(journal_t *journal, tid_t 
*tid,
  *
  * Requires j_checkpoint_mutex
  */
-void __jbd2_update_log_tail(journal_t *journal, tid_t tid, unsigned long block)
+int __jbd2_update_log_tail(journal_t *journal, tid_t tid, unsigned long block)
 {
unsigned long freed;
+   int ret;
 
BUG_ON(!mutex_is_locked(>j_checkpoint_mutex));
 
@@ -835,7 +836,10 @@ void __jbd2_update_log_tail(journal_t *journal, tid_t tid, 
unsigned long block)
 * space and if we lose sb update during power failure we'd replay
 * old transaction with possibly newly overwritten data.
 */
-   jbd2_journal_update_sb_log_tail(journal, tid, block, WRITE_FUA);
+   ret = jbd2_journal_update_sb_log_tail(journal, tid, block, WRITE_FUA);
+   if (ret)
+   goto out;
+
write_lock(>j_state_lock);
freed = block - journal->j_tail;
if (block < journal->j_tail)
@@ -851,6 +855,9 @@ void __jbd2_update_log_tail(journal_t *journal, tid_t tid, 
unsigned long block)
journal->j_tail_sequence = tid;
journal->j_tail = block;
write_unlock(>j_state_lock);
+
+out:
+   return ret;
 }
 
 /*
@@ -1264,7 +1271,7 @@ static int journal_reset(journal_t *journal)
return jbd2_journal_start_thread(journal);
 }
 
-static void jbd2_write_superblock(journal_t *journal, int write_op)
+static int jbd2_write_superblock(journal_t *journal, int write_op)
 {
struct buffer_head *bh = journal->j_sb_buffer;
int ret;
@@ -1301,7 +1308,10 @@ static void jbd2_write_superblock(journal_t *journal, 
int write_op)
printk(KERN_ERR "JBD2: Error %d detected when updating "
   "journal superblock for %s.\n", ret,
   journal->j_devname);
+   jbd2_journal_abort(journal, ret);
}
+
+   return ret;
 }
 
 /**
@@ -1314,10 +1324,11 @@ static void jbd2_write_superblock(journal_t *journal, 
int write_op)
  * Update a journal's superblock information about log tail and write it to
  * disk, waiting for the IO to complete.
  */
-void jbd2_journal_update_sb_log_tail(journal_t *journal, tid_t tail_tid,
+int jbd2_journal_update_sb_log_tail(journal_t *journal, tid_t tail_tid,
 unsigned long tail_block, int write_op)
 {
journal_superblock_t *sb = journal->j_superblock;
+   int ret;
 
BUG_ON(!mutex_is_locked(>j_checkpoint_mutex));
jbd_debug(1, "JBD2: updating superblock (start %lu, seq %u)\n",
@@ -1326,13 +1337,18 @@ 

[PATCH 3.4 35/65] nfs: increase size of EXCHANGE_ID name string buffer

[lizf]

From: Jeff Layton 

3.4.110-rc1 review patch.  If anyone has any objections, please let me know.

--


commit 764ad8ba8cd4c6f836fca9378f8c5121aece0842 upstream.

The current buffer is much too small if you have a relatively long
hostname. Bring it up to the size of the one that SETCLIENTID has.

Reported-by: Michael Skralivetsky 
Signed-off-by: Jeff Layton 
Signed-off-by: Trond Myklebust 
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li 
---
 include/linux/nfs_xdr.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/nfs_xdr.h b/include/linux/nfs_xdr.h
index 7ba3551..845b402 100644
--- a/include/linux/nfs_xdr.h
+++ b/include/linux/nfs_xdr.h
@@ -1061,7 +1061,7 @@ struct nfstime4 {
 };
 
 #ifdef CONFIG_NFS_V4_1
-#define NFS4_EXCHANGE_ID_LEN   (48)
+#define NFS4_EXCHANGE_ID_LEN   (127)
 struct nfs41_exchange_id_args {
struct nfs_client   *client;
nfs4_verifier   *verifier;
-- 
1.9.1

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

[PATCH 3.4 36/65] bridge: fix br_stp_set_bridge_priority race conditions

[lizf]

From: Nikolay Aleksandrov 

3.4.110-rc1 review patch.  If anyone has any objections, please let me know.

--


commit 2dab80a8b486f0a69daca6859519e05781d9 upstream.

After the ->set() spinlocks were removed br_stp_set_bridge_priority
was left running without any protection when used via sysfs. It can
race with port add/del and could result in use-after-free cases and
corrupted lists. Tested by running port add/del in a loop with stp
enabled while setting priority in a loop, crashes are easily
reproducible.
The spinlocks around sysfs ->set() were removed in commit:
14f98f258f19 ("bridge: range check STP parameters")
There's also a race condition in the netlink priority support that is
fixed by this change, but it was introduced recently and the fixes tag
covers it, just in case it's needed the commit is:
af615762e972 ("bridge: add ageing_time, stp_state, priority over netlink")

Signed-off-by: Nikolay Aleksandrov 
Fixes: 14f98f258f19 ("bridge: range check STP parameters")
Signed-off-by: David S. Miller 
Signed-off-by: Zefan Li 
---
 net/bridge/br_ioctl.c  | 2 --
 net/bridge/br_stp_if.c | 4 +++-
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/net/bridge/br_ioctl.c b/net/bridge/br_ioctl.c
index 7222fe1..ea0e15c 100644
--- a/net/bridge/br_ioctl.c
+++ b/net/bridge/br_ioctl.c
@@ -246,9 +246,7 @@ static int old_dev_ioctl(struct net_device *dev, struct 
ifreq *rq, int cmd)
if (!capable(CAP_NET_ADMIN))
return -EPERM;
 
-   spin_lock_bh(>lock);
br_stp_set_bridge_priority(br, args[1]);
-   spin_unlock_bh(>lock);
return 0;
 
case BRCTL_SET_PORT_PRIORITY:
diff --git a/net/bridge/br_stp_if.c b/net/bridge/br_stp_if.c
index 2f100cc..23ea159 100644
--- a/net/bridge/br_stp_if.c
+++ b/net/bridge/br_stp_if.c
@@ -242,12 +242,13 @@ bool br_stp_recalculate_bridge_id(struct net_bridge *br)
return true;
 }
 
-/* called under bridge lock */
+/* Acquires and releases bridge lock */
 void br_stp_set_bridge_priority(struct net_bridge *br, u16 newprio)
 {
struct net_bridge_port *p;
int wasroot;
 
+   spin_lock_bh(>lock);
wasroot = br_is_root_bridge(br);
 
list_for_each_entry(p, >port_list, list) {
@@ -265,6 +266,7 @@ void br_stp_set_bridge_priority(struct net_bridge *br, u16 
newprio)
br_port_state_selection(br);
if (br_is_root_bridge(br) && !wasroot)
br_become_root_bridge(br);
+   spin_unlock_bh(>lock);
 }
 
 /* called under bridge lock */
-- 
1.9.1

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

[PATCH 3.4 40/65] ext4: don't retry file block mapping on bigalloc fs with non-extent file

[lizf]

From: "Darrick J. Wong" 

3.4.110-rc1 review patch.  If anyone has any objections, please let me know.

--


commit 292db1bc6c105d86111e858859456bcb11f90f91 upstream.

ext4 isn't willing to map clusters to a non-extent file.  Don't signal
this with an out of space error, since the FS will retry the
allocation (which didn't fail) forever.  Instead, return EUCLEAN so
that the operation will fail immediately all the way back to userspace.

(The fix is either to run e2fsck -E bmap2extent, or to chattr +e the file.)

Signed-off-by: Darrick J. Wong 
Signed-off-by: Theodore Ts'o 
Signed-off-by: Zefan Li 
---
 fs/ext4/indirect.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/ext4/indirect.c b/fs/ext4/indirect.c
index 6dc6153..f819837 100644
--- a/fs/ext4/indirect.c
+++ b/fs/ext4/indirect.c
@@ -705,7 +705,7 @@ int ext4_ind_map_blocks(handle_t *handle, struct inode 
*inode,
   EXT4_FEATURE_RO_COMPAT_BIGALLOC)) {
EXT4_ERROR_INODE(inode, "Can't allocate blocks for "
 "non-extent mapped inodes with bigalloc");
-   return -ENOSPC;
+   return -EUCLEAN;
}
 
goal = ext4_find_goal(inode, map->m_lblk, partial);
-- 
1.9.1

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

[PATCH 3.4 37/65] ext4: call sync_blockdev() before invalidate_bdev() in put_super()

[lizf]

From: Theodore Ts'o 

3.4.110-rc1 review patch.  If anyone has any objections, please let me know.

--


commit 89d96a6f8e6491f24fc8f99fd6ae66820e85c6c1 upstream.

Normally all of the buffers will have been forced out to disk before
we call invalidate_bdev(), but there will be some cases, where a file
system operation was aborted due to an ext4_error(), where there may
still be some dirty buffers in the buffer cache for the device.  So
try to force them out to memory before calling invalidate_bdev().

This fixes a warning triggered by generic/081:

WARNING: CPU: 1 PID: 3473 at /usr/projects/linux/ext4/fs/block_dev.c:56 
__blkdev_put+0xb5/0x16f()

Signed-off-by: Theodore Ts'o 
Signed-off-by: Zefan Li 
---
 fs/ext4/super.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 92ea560..2e26a54 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -888,6 +888,7 @@ static void ext4_put_super(struct super_block *sb)
dump_orphan_list(sb, sbi);
J_ASSERT(list_empty(>s_orphan));
 
+   sync_blockdev(sb->s_bdev);
invalidate_bdev(sb->s_bdev);
if (sbi->journal_bdev && sbi->journal_bdev != sb->s_bdev) {
/*
-- 
1.9.1

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

[PATCH 3.4 42/65] bridge: multicast: restore router configuration on port link down/up

[lizf]

From: Satish Ashok 

3.4.110-rc1 review patch.  If anyone has any objections, please let me know.

--


commit 754bc547f0a79f7568b5b81c7fc0a8d044a6571a upstream.

When a port goes through a link down/up the multicast router configuration
is not restored.

Signed-off-by: Satish Ashok 
Signed-off-by: Nikolay Aleksandrov 
Fixes: 0909e11758bd ("bridge: Add multicast_router sysfs entries")
Acked-by: Herbert Xu 
Signed-off-by: David S. Miller 
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li 
---
 net/bridge/br_multicast.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index a41051a..87ae8c3 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -36,6 +36,9 @@
 #define mlock_dereference(X, br) \
rcu_dereference_protected(X, lockdep_is_held(>multicast_lock))
 
+static void br_multicast_add_router(struct net_bridge *br,
+   struct net_bridge_port *port);
+
 #if IS_ENABLED(CONFIG_IPV6)
 static inline int ipv6_is_transient_multicast(const struct in6_addr *addr)
 {
@@ -842,6 +845,8 @@ void br_multicast_enable_port(struct net_bridge_port *port)
goto out;
 
__br_multicast_enable_port(port);
+   if (port->multicast_router == 2 && hlist_unhashed(>rlist))
+   br_multicast_add_router(br, port);
 
 out:
spin_unlock(>multicast_lock);
-- 
1.9.1

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

[PATCH 3.4 44/65] mm: kmemleak: allow safe memory scanning during kmemleak disabling

[lizf]

From: Catalin Marinas 

3.4.110-rc1 review patch.  If anyone has any objections, please let me know.

--


commit c5f3b1a51a591c18c8b33983908e7fdda6ae417e upstream.

The kmemleak scanning thread can run for minutes.  Callbacks like
kmemleak_free() are allowed during this time, the race being taken care
of by the object->lock spinlock.  Such lock also prevents a memory block
from being freed or unmapped while it is being scanned by blocking the
kmemleak_free() -> ...  -> __delete_object() function until the lock is
released in scan_object().

When a kmemleak error occurs (e.g.  it fails to allocate its metadata),
kmemleak_enabled is set and __delete_object() is no longer called on
freed objects.  If kmemleak_scan is running at the same time,
kmemleak_free() no longer waits for the object scanning to complete,
allowing the corresponding memory block to be freed or unmapped (in the
case of vfree()).  This leads to kmemleak_scan potentially triggering a
page fault.

This patch separates the kmemleak_free() enabling/disabling from the
overall kmemleak_enabled nob so that we can defer the disabling of the
object freeing tracking until the scanning thread completed.  The
kmemleak_free_part() is deliberately ignored by this patch since this is
only called during boot before the scanning thread started.

Signed-off-by: Catalin Marinas 
Reported-by: Vignesh Radhakrishnan 
Tested-by: Vignesh Radhakrishnan 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li 
---
 mm/kmemleak.c | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index ad6ee88..c74827c 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -193,6 +193,8 @@ static struct kmem_cache *scan_area_cache;
 
 /* set if tracing memory operations is enabled */
 static atomic_t kmemleak_enabled = ATOMIC_INIT(0);
+/* same as above but only for the kmemleak_free() callback */
+static int kmemleak_free_enabled;
 /* set in the late_initcall if there were no errors */
 static atomic_t kmemleak_initialized = ATOMIC_INIT(0);
 /* enables or disables early logging of the memory operations */
@@ -936,7 +938,7 @@ void __ref kmemleak_free(const void *ptr)
 {
pr_debug("%s(0x%p)\n", __func__, ptr);
 
-   if (atomic_read(_enabled) && ptr && !IS_ERR(ptr))
+   if (kmemleak_free_enabled && ptr && !IS_ERR(ptr))
delete_object_full((unsigned long)ptr);
else if (atomic_read(_early_log))
log_early(KMEMLEAK_FREE, ptr, 0, 0);
@@ -976,7 +978,7 @@ void __ref kmemleak_free_percpu(const void __percpu *ptr)
 
pr_debug("%s(0x%p)\n", __func__, ptr);
 
-   if (atomic_read(_enabled) && ptr && !IS_ERR(ptr))
+   if (kmemleak_free_enabled && ptr && !IS_ERR(ptr))
for_each_possible_cpu(cpu)
delete_object_full((unsigned long)per_cpu_ptr(ptr,
  cpu));
@@ -1690,6 +1692,13 @@ static void kmemleak_do_cleanup(struct work_struct *work)
mutex_lock(_mutex);
stop_scan_thread();
 
+   /*
+* Once the scan thread has stopped, it is safe to no longer track
+* object freeing. Ordering of the scan thread stopping and the memory
+* accesses below is guaranteed by the kthread_stop() function.
+ */
+   kmemleak_free_enabled = 0;
+
if (cleanup) {
rcu_read_lock();
list_for_each_entry_rcu(object, _list, object_list)
@@ -1717,6 +1726,8 @@ static void kmemleak_disable(void)
/* check whether it is too early for a kernel thread */
if (atomic_read(_initialized))
schedule_work(_work);
+   else
+   kmemleak_free_enabled = 0;
 
pr_info("Kernel memory leak detector disabled\n");
 }
@@ -1782,8 +1793,10 @@ void __init kmemleak_init(void)
if (atomic_read(_error)) {
local_irq_restore(flags);
return;
-   } else
+   } else {
atomic_set(_enabled, 1);
+   kmemleak_free_enabled = 1;
+   }
local_irq_restore(flags);
 
/*
-- 
1.9.1

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

[PATCH 3.4 46/65] tracing/filter: Do not WARN on operand count going below zero

[lizf]

From: "Steven Rostedt (Red Hat)" 

3.4.110-rc1 review patch.  If anyone has any objections, please let me know.

--


commit b4875bbe7e68f139bd3383828ae8e994a0df6d28 upstream.

When testing the fix for the trace filter, I could not come up with
a scenario where the operand count goes below zero, so I added a
WARN_ON_ONCE(cnt < 0) to the logic. But there is legitimate case
that it can happen (although the filter would be wrong).

 # echo '>' > /sys/kernel/debug/events/ext4/ext4_truncate_exit/filter

That is, a single operation without any operands will hit the path
where the WARN_ON_ONCE() can trigger. Although this is harmless,
and the filter is reported as a error. But instead of spitting out
a warning to the kernel dmesg, just fail nicely and report it via
the proper channels.

Link: http://lkml.kernel.org/r/558c6082.90...@oracle.com

Reported-by: Vince Weaver 
Reported-by: Sasha Levin 
Signed-off-by: Steven Rostedt 
Signed-off-by: Zefan Li 
---
 kernel/trace/trace_events_filter.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/kernel/trace/trace_events_filter.c 
b/kernel/trace/trace_events_filter.c
index 3b04aec..ae6c572 100644
--- a/kernel/trace/trace_events_filter.c
+++ b/kernel/trace/trace_events_filter.c
@@ -1372,7 +1372,9 @@ static int check_preds(struct filter_parse_state *ps)
}
cnt--;
n_normal_preds++;
-   WARN_ON_ONCE(cnt < 0);
+   /* all ops should have operands */
+   if (cnt < 0)
+   break;
}
 
if (cnt != 1 || !n_normal_preds || n_logical_preds >= n_normal_preds) {
-- 
1.9.1

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

[PATCH 3.4 50/65] crush: fix a bug in tree bucket decode

[lizf]

From: Ilya Dryomov 

3.4.110-rc1 review patch.  If anyone has any objections, please let me know.

--


commit 82cd003a77173c91b9acad8033fb7931dac8d751 upstream.

struct crush_bucket_tree::num_nodes is u8, so ceph_decode_8_safe()
should be used.  -Wconversion catches this, but I guess it went
unnoticed in all the noise it spews.  The actual problem (at least for
common crushmaps) isn't the u32 -> u8 truncation though - it's the
advancement by 4 bytes instead of 1 in the crushmap buffer.

Fixes: http://tracker.ceph.com/issues/2759

Signed-off-by: Ilya Dryomov 
Reviewed-by: Josh Durgin 
Signed-off-by: Zefan Li 
---
 net/ceph/osdmap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ceph/osdmap.c b/net/ceph/osdmap.c
index 7fbe210..d4fbcb6 100644
--- a/net/ceph/osdmap.c
+++ b/net/ceph/osdmap.c
@@ -102,7 +102,7 @@ static int crush_decode_tree_bucket(void **p, void *end,
 {
int j;
dout("crush_decode_tree_bucket %p to %p\n", *p, end);
-   ceph_decode_32_safe(p, end, b->num_nodes, bad);
+   ceph_decode_8_safe(p, end, b->num_nodes, bad);
b->node_weights = kcalloc(b->num_nodes, sizeof(u32), GFP_NOFS);
if (b->node_weights == NULL)
return -ENOMEM;
-- 
1.9.1

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

[PATCH 3.4 49/65] agp/intel: Fix typo in needs_ilk_vtd_wa()

[lizf]

From: Chris Wilson 

3.4.110-rc1 review patch.  If anyone has any objections, please let me know.

--


commit 8b572a4200828b4e75cc22ed2f494b58d5372d65 upstream.

In needs_ilk_vtd_wa(), we pass in the GPU device but compared it against
the ids for the mobile GPU and the mobile host bridge. That latter is
impossible and so likely was just a typo for the desktop GPU device id
(which is also buggy).

Fixes commit da88a5f7f7d434e2cde1b3e19d952e6d84533662
Author: Chris Wilson 
Date:   Wed Feb 13 09:31:53 2013 +

drm/i915: Disable WC PTE updates to w/a buggy IOMMU on ILK

Reported-by: Ting-Wei Lan 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=91127
References: https://bugzilla.freedesktop.org/show_bug.cgi?id=60391
Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
Reviewed-by: Daniel Vetter 
Signed-off-by: Jani Nikula 
Signed-off-by: Zefan Li 
---
 drivers/char/agp/intel-gtt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/agp/intel-gtt.c b/drivers/char/agp/intel-gtt.c
index 7f025fb..4e985cd 100644
--- a/drivers/char/agp/intel-gtt.c
+++ b/drivers/char/agp/intel-gtt.c
@@ -1194,7 +1194,7 @@ static inline int needs_idle_maps(void)
/* Query intel_iommu to see if we need the workaround. Presumably that
 * was loaded first.
 */
-   if ((gpu_devid == PCI_DEVICE_ID_INTEL_IRONLAKE_M_HB ||
+   if ((gpu_devid == PCI_DEVICE_ID_INTEL_IRONLAKE_D_IG ||
 gpu_devid == PCI_DEVICE_ID_INTEL_IRONLAKE_M_IG) &&
 intel_iommu_gfx_mapped)
return 1;
-- 
1.9.1

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

Re: [PATCH] posix-cpu-timers: Merge running and checking_timer state in one field

[Frederic Weisbecker]

On Mon, Oct 19, 2015 at 05:41:08PM -0700, Davidlohr Bueso wrote:
> On Tue, 20 Oct 2015, Frederic Weisbecker wrote:
> 
> >- * @checking_timer: true when a thread in the group is in the
> >- *  process of checking for thread group timers.
> >- *
> >+ * @state:  flags describing the current state of the cputimer.
> >+ *  CPUTIMER_STATE_RUNNING bit means the timers is elapsing.
> 
>  s/timers/timer
> 
> >+ *  CPUTIMER_STATE_CHECKING bit means that the cputimer has
> >+ *  expired and a thread in the group is checking the
> >+ *  callback list.
> 
> These comments might be better served when defining CPUTIMER_STATE_*

If it was defined as an emum I'd agree but here state is defined as an
int (whose size is more readable in a struct than enum) and it's not obvious
what kind of values it can take if we don't define them here.

> 
> [...]
> 
> >@@ -606,7 +606,7 @@ bool posix_cpu_timers_can_stop_tick(struct task_struct 
> >*tsk)
> > return false;
> >
> > /* Check if cputimer is running. This is accessed without locking. */
> >-if (READ_ONCE(tsk->signal->cputimer.running))
> >+if (READ_ONCE(tsk->signal->cputimer.state))
> > return false;
> 
> Could we have cases, such as the above, where .state is set to 
> CPUTIMER_STATE_CHECKING
> and therefore the check is not equivalent?

Nope we shouldn't. I added a WARN_ONCE somewhere to perform some related sanity
checks. I could add more if needed.

Thanks.

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

[PATCH 3.4 53/65] KVM: x86: make vapics_in_nmi_mode atomic

[lizf]

From: Radim Krčmář 

3.4.110-rc1 review patch.  If anyone has any objections, please let me know.

--


commit 42720138b06301cc8a7ee8a495a6d021c4b6a9bc upstream.

Writes were a bit racy, but hard to turn into a bug at the same time.
(Particularly because modern Linux doesn't use this feature anymore.)

Signed-off-by: Radim Krčmář 
[Actually the next patch makes it much, much easier to trigger the race
 so I'm including this one for stable@ as well. - Paolo]
Signed-off-by: Paolo Bonzini 
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li 
---
 arch/x86/include/asm/kvm_host.h | 2 +-
 arch/x86/kvm/i8254.c| 2 +-
 arch/x86/kvm/lapic.c| 4 ++--
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 4f78757..d60facb 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -509,7 +509,7 @@ struct kvm_arch {
struct kvm_pic *vpic;
struct kvm_ioapic *vioapic;
struct kvm_pit *vpit;
-   int vapics_in_nmi_mode;
+   atomic_t vapics_in_nmi_mode;
 
unsigned int tss_addr;
struct page *apic_access_page;
diff --git a/arch/x86/kvm/i8254.c b/arch/x86/kvm/i8254.c
index db336f9..eaad49a 100644
--- a/arch/x86/kvm/i8254.c
+++ b/arch/x86/kvm/i8254.c
@@ -317,7 +317,7 @@ static void pit_do_work(struct work_struct *work)
 * LVT0 to NMI delivery. Other PIC interrupts are just sent to
 * VCPU0, and only if its LVT0 is in EXTINT mode.
 */
-   if (kvm->arch.vapics_in_nmi_mode > 0)
+   if (atomic_read(>arch.vapics_in_nmi_mode) > 0)
kvm_for_each_vcpu(i, vcpu, kvm)
kvm_apic_nmi_wd_deliver(vcpu);
}
diff --git a/arch/x86/kvm/lapic.c b/arch/x86/kvm/lapic.c
index 578613d..f935b52 100644
--- a/arch/x86/kvm/lapic.c
+++ b/arch/x86/kvm/lapic.c
@@ -761,10 +761,10 @@ static void apic_manage_nmi_watchdog(struct kvm_lapic 
*apic, u32 lvt0_val)
if (!nmi_wd_enabled) {
apic_debug("Receive NMI setting on APIC_LVT0 "
   "for cpu %d\n", apic->vcpu->vcpu_id);
-   apic->vcpu->kvm->arch.vapics_in_nmi_mode++;
+   atomic_inc(>vcpu->kvm->arch.vapics_in_nmi_mode);
}
} else if (nmi_wd_enabled)
-   apic->vcpu->kvm->arch.vapics_in_nmi_mode--;
+   atomic_dec(>vcpu->kvm->arch.vapics_in_nmi_mode);
 }
 
 static int apic_reg_write(struct kvm_lapic *apic, u32 reg, u32 val)
-- 
1.9.1

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