RE: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)

[Jun Li]

Hi Guenter

> -Original Message-
> From: Guenter Roeck [mailto:gro...@google.com]
> Sent: Saturday, September 10, 2016 10:23 AM
> To: Jun Li 
> Cc: Guenter Roeck ; Felipe Balbi
> ; Chandra Sekhar Anagani
> ; Bruce Ashfield
> ; Bin Gao ; Pranav Tipnis
> ; Heikki Krogerus
> ; linux-kernel@vger.kernel.org; linux-
> u...@vger.kernel.org
> Subject: Re: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)
> 
> On Fri, Sep 9, 2016 at 5:26 PM, Jun Li  wrote:
> > Hi Guenter,
> >
> >> -Original Message-
> >> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> >> ow...@vger.kernel.org] On Behalf Of Guenter Roeck
> >> Sent: Wednesday, August 24, 2016 5:11 AM
> >> To: Felipe Balbi 
> >> Cc: Chandra Sekhar Anagani ; Bruce
> >> Ashfield ; Bin Gao ;
> >> Pranav Tipnis ; Heikki Krogerus
> >> ; linux-kernel@vger.kernel.org;
> >> linux- u...@vger.kernel.org; Guenter Roeck 
> >> Subject: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager
> >> (tcpm)
> >>
> >> This driver implements the USB Type-C Power Delivery state machine
> >> for both source and sink ports. Alternate mode support is not fully
> >> implemented.
> >>
> >> The driver attaches to the USB Type-C class code implemented in the
> >> following patches.
> >>
> >>   usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY
> >>   usb: USB Type-C connector class
> >>
> >> This driver only implements the state machine. Lower level drivers
> >> are responsible for
> >> - Reporting VBUS status and activating VBUS
> >> - Setting CC lines and providing CC line status
> >> - Setting line polarity
> >> - Activating and deactivating VCONN
> >> - Setting the current limit
> >> - Activating and deactivating PD message transfers
> >> - Sending and receiving PD messages
> >>
> >> The driver provides both a functional API as well as callbacks for
> >> lower level drivers.
> >>
> >> Signed-off-by: Guenter Roeck 
> >> ---
> >
> > A specific question, if power sink wants to request a new power level
> > after SNK_READY, how to handle it with this tcpm?
> >
> 
> So far I have considered the required power level to be static, based on
> our curent implementations. That should be easy to change, though, with an
> additional API function, to be called from a low level driver.
> Do you have that requirement, and would such a function meet your needs ?
> 

So you are going to make port->tcpc->config to be dynamic to meet my need?

Li Jun
 
> Thanks,
> Guenter

RE: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)

[Jun Li]

Hi Guenter

> -Original Message-
> From: Guenter Roeck [mailto:gro...@google.com]
> Sent: Saturday, September 10, 2016 10:23 AM
> To: Jun Li 
> Cc: Guenter Roeck ; Felipe Balbi
> ; Chandra Sekhar Anagani
> ; Bruce Ashfield
> ; Bin Gao ; Pranav Tipnis
> ; Heikki Krogerus
> ; linux-kernel@vger.kernel.org; linux-
> u...@vger.kernel.org
> Subject: Re: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)
> 
> On Fri, Sep 9, 2016 at 5:26 PM, Jun Li  wrote:
> > Hi Guenter,
> >
> >> -Original Message-
> >> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> >> ow...@vger.kernel.org] On Behalf Of Guenter Roeck
> >> Sent: Wednesday, August 24, 2016 5:11 AM
> >> To: Felipe Balbi 
> >> Cc: Chandra Sekhar Anagani ; Bruce
> >> Ashfield ; Bin Gao ;
> >> Pranav Tipnis ; Heikki Krogerus
> >> ; linux-kernel@vger.kernel.org;
> >> linux- u...@vger.kernel.org; Guenter Roeck 
> >> Subject: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager
> >> (tcpm)
> >>
> >> This driver implements the USB Type-C Power Delivery state machine
> >> for both source and sink ports. Alternate mode support is not fully
> >> implemented.
> >>
> >> The driver attaches to the USB Type-C class code implemented in the
> >> following patches.
> >>
> >>   usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY
> >>   usb: USB Type-C connector class
> >>
> >> This driver only implements the state machine. Lower level drivers
> >> are responsible for
> >> - Reporting VBUS status and activating VBUS
> >> - Setting CC lines and providing CC line status
> >> - Setting line polarity
> >> - Activating and deactivating VCONN
> >> - Setting the current limit
> >> - Activating and deactivating PD message transfers
> >> - Sending and receiving PD messages
> >>
> >> The driver provides both a functional API as well as callbacks for
> >> lower level drivers.
> >>
> >> Signed-off-by: Guenter Roeck 
> >> ---
> >
> > A specific question, if power sink wants to request a new power level
> > after SNK_READY, how to handle it with this tcpm?
> >
> 
> So far I have considered the required power level to be static, based on
> our curent implementations. That should be easy to change, though, with an
> additional API function, to be called from a low level driver.
> Do you have that requirement, and would such a function meet your needs ?
> 

So you are going to make port->tcpc->config to be dynamic to meet my need?

Li Jun
 
> Thanks,
> Guenter

ACPI/APD Making Module

[Shah, Nehal-bakulchandra]

Hi,
Current implementation of acpi_apd.c makes AMD I2C,GPIO and UART from acpi 
devices to platform devices. This is done as part of boot sequence.  For some 
reason i would like to make it kernel module. The current implementation calls 
acpi_apd_create_device as part of attach callback. Now this entire process is 
part of acpi bus scan functionality. Can someone please help me if i can make 
this file into kernel module and still get the same functionality.

Thanks 
Nehal

linux-next: Tree for Sep 12

[Stephen Rothwell]

Hi all,

Changes since 20160909:

The arm64 tree gained a conflict against Linus' tree.

The btrfs-kdave tree lost its build failure.

The v4l-dvb tree gained a build failure for which I reverted a commit.

The net-next tree gained a conflict against the net tree.

The kbuild tree still had its build warnings for PowerPC, for which I
reverted a commit and gained a conflict against Linus' tree.

The tip tree gained a conflict against the arm64 tree.

The gpio tree still had its build failure, so I used the version from
next-20160908.

Non-merge commits (relative to Linus' tree): 6495
 6444 files changed, 311206 insertions(+), 197237 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 (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 241 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 Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (98ac9a608dc7 Merge branch 'libnvdimm-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm)
Merging fixes/master (d3396e1e4ec4 Merge tag 'fixes-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging kbuild-current/rc-fixes (d3e2773c4ede builddeb: Skip gcc-plugins when 
not configured)
Merging arc-current/for-curr (3eab887a5542 Linux 4.8-rc4)
Merging arm-current/fixes (da60626e7d02 ARM: sa1100: clear reset status prior 
to reboot)
Merging m68k-current/for-linus (6bd80f372371 m68k/defconfig: Update defconfigs 
for v4.7-rc2)
Merging metag-fixes/fixes (97b1d23f7bcb metag: Drop show_mem() from mem_init())
Merging powerpc-fixes/fixes (f077aaf0754b powerpc/mm: Don't alias user region 
to other regions below PAGE_OFFSET)
Merging sparc/master (4620a06e4b3c shmem: Fix link error if huge pages support 
is disabled)
Merging net/master (e1487888eccc net: ethernet: renesas: sh_eth: add POST 
registers for rz)
Merging ipsec/master (1fb81e09d487 vti: use right inner_mode for inbound inter 
address family policy checks)
Merging netfilter/master (d1a6cba576fc netfilter: nft_chain_route: re-route 
before skb is queued to userspace)
Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging wireless-drivers/master (a0714125d11b Merge ath-current from ath.git)
Merging mac80211/master (61aaa0e8c1c1 cfg80211: Add stub for 
cfg80211_get_station())
Merging sound-current/for-linus (3f640970a414 ALSA: hda - Fix headset mic 
detection problem for several Dell laptops)
Merging pci-current/for-linus (6af7e4f77259 PCI: Mark Haswell Power Control 
Unit as having non-compliant BARs)
Merging driver-core.current/driver-core-linus (c6935931c189 Linux 4.8-rc5)
Merging tty.current/tty-linus (c6935931c189 Linux 4.8-rc5)
Merging usb.current/usb-linus (6b98174b957c Merge tag 'fixes-for-v4.8-rc6' of 
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus)
Merging usb-gadget-fixes/fixes (696118c016dd usb: dwc3: pci: fix build warning 
on !PM_SLEEP)
Merging usb-serial-fixes/usb-linus (40d9c32525cb USB: serial: option: add 
WeTelecom 0x6802 and 0x6803 products)
Merging usb-chipidea-fixes/ci-for-usb-stable (6f3c4fb6d05e usb: chipidea: udc: 
fix NULL ptr dereference in isr_setup_status_phase)
Merging staging.current/staging-linus (72d508ad488a Merge tag 
'iio-fixes-for-4.8b' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio 
into staging-linus)
Merging char-misc.current/char-misc-linus (c6935931c189 Linux 4.8-rc5)
Merging input-current/for-linus (4af2ff91ec3f Input: silead_gsl1680 - use 

ACPI/APD Making Module

[Shah, Nehal-bakulchandra]

Hi,
Current implementation of acpi_apd.c makes AMD I2C,GPIO and UART from acpi 
devices to platform devices. This is done as part of boot sequence.  For some 
reason i would like to make it kernel module. The current implementation calls 
acpi_apd_create_device as part of attach callback. Now this entire process is 
part of acpi bus scan functionality. Can someone please help me if i can make 
this file into kernel module and still get the same functionality.

Thanks 
Nehal

linux-next: Tree for Sep 12

[Stephen Rothwell]

Hi all,

Changes since 20160909:

The arm64 tree gained a conflict against Linus' tree.

The btrfs-kdave tree lost its build failure.

The v4l-dvb tree gained a build failure for which I reverted a commit.

The net-next tree gained a conflict against the net tree.

The kbuild tree still had its build warnings for PowerPC, for which I
reverted a commit and gained a conflict against Linus' tree.

The tip tree gained a conflict against the arm64 tree.

The gpio tree still had its build failure, so I used the version from
next-20160908.

Non-merge commits (relative to Linus' tree): 6495
 6444 files changed, 311206 insertions(+), 197237 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 (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 241 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 Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (98ac9a608dc7 Merge branch 'libnvdimm-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm)
Merging fixes/master (d3396e1e4ec4 Merge tag 'fixes-for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc)
Merging kbuild-current/rc-fixes (d3e2773c4ede builddeb: Skip gcc-plugins when 
not configured)
Merging arc-current/for-curr (3eab887a5542 Linux 4.8-rc4)
Merging arm-current/fixes (da60626e7d02 ARM: sa1100: clear reset status prior 
to reboot)
Merging m68k-current/for-linus (6bd80f372371 m68k/defconfig: Update defconfigs 
for v4.7-rc2)
Merging metag-fixes/fixes (97b1d23f7bcb metag: Drop show_mem() from mem_init())
Merging powerpc-fixes/fixes (f077aaf0754b powerpc/mm: Don't alias user region 
to other regions below PAGE_OFFSET)
Merging sparc/master (4620a06e4b3c shmem: Fix link error if huge pages support 
is disabled)
Merging net/master (e1487888eccc net: ethernet: renesas: sh_eth: add POST 
registers for rz)
Merging ipsec/master (1fb81e09d487 vti: use right inner_mode for inbound inter 
address family policy checks)
Merging netfilter/master (d1a6cba576fc netfilter: nft_chain_route: re-route 
before skb is queued to userspace)
Merging ipvs/master (ea43f860d984 Merge branch 'ethoc-fixes')
Merging wireless-drivers/master (a0714125d11b Merge ath-current from ath.git)
Merging mac80211/master (61aaa0e8c1c1 cfg80211: Add stub for 
cfg80211_get_station())
Merging sound-current/for-linus (3f640970a414 ALSA: hda - Fix headset mic 
detection problem for several Dell laptops)
Merging pci-current/for-linus (6af7e4f77259 PCI: Mark Haswell Power Control 
Unit as having non-compliant BARs)
Merging driver-core.current/driver-core-linus (c6935931c189 Linux 4.8-rc5)
Merging tty.current/tty-linus (c6935931c189 Linux 4.8-rc5)
Merging usb.current/usb-linus (6b98174b957c Merge tag 'fixes-for-v4.8-rc6' of 
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb into usb-linus)
Merging usb-gadget-fixes/fixes (696118c016dd usb: dwc3: pci: fix build warning 
on !PM_SLEEP)
Merging usb-serial-fixes/usb-linus (40d9c32525cb USB: serial: option: add 
WeTelecom 0x6802 and 0x6803 products)
Merging usb-chipidea-fixes/ci-for-usb-stable (6f3c4fb6d05e usb: chipidea: udc: 
fix NULL ptr dereference in isr_setup_status_phase)
Merging staging.current/staging-linus (72d508ad488a Merge tag 
'iio-fixes-for-4.8b' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio 
into staging-linus)
Merging char-misc.current/char-misc-linus (c6935931c189 Linux 4.8-rc5)
Merging input-current/for-linus (4af2ff91ec3f Input: silead_gsl1680 - use 

Re: [patch v1] x86/platform/mellanox: introduce support for Mellanox systems platform

[Guenter Roeck]

On 09/11/2016 11:29 PM, vad...@mellanox.com wrote:

From: Vadim Pasternak 

Enable system support for the Mellanox Technologies platform, which
provides support for the next Mellanox basic systems: "msx6710",
"msx6720", "msb7700", "msn2700", "msx1410", "msn2410", "msb7800",
"msn2740", "msn2100" and also various number of derivative systems from
the above basic types.

The Kconfig currently controlling compilation of this code is:
arch/x86/platform:config MLX_PLATFORM
arch/x86/platform:  tristate "Mellanox Technologies platform support"

Signed-off-by: Vadim Pasternak 
---
 MAINTAINERS   |   7 +
 arch/x86/Kconfig  |  23 ++
 arch/x86/platform/Makefile|   1 +
 arch/x86/platform/mellanox/Makefile   |   1 +
 arch/x86/platform/mellanox/mlx-platform.c | 501 ++
 5 files changed, 533 insertions(+)
 create mode 100644 arch/x86/platform/mellanox/Makefile
 create mode 100644 arch/x86/platform/mellanox/mlx-platform.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 4705c94..8a675de 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7664,6 +7664,13 @@ W:   http://www.mellanox.com
 Q: http://patchwork.ozlabs.org/project/netdev/list/
 F: drivers/net/ethernet/mellanox/mlxsw/

+MELLANOX PLATFORM DRIVER
+M:  Vadim Pasternak 
+L:  platform-driver-...@vger.kernel.org
+S:  Supported
+W:  http://www.mellanox.com
+F:  arch/x86/platform/mellanox/mlx-platform.c
+
 SOFT-ROCE DRIVER (rxe)
 M: Moni Shoua 
 L: linux-r...@vger.kernel.org
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index c580d8c..cc7efdd9 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2631,6 +2631,29 @@ config TS5500

 endif # X86_32

+config MLX_PLATFORM
+   tristate "Mellanox Technologies platform support"
+   depends on X86_64
+   depends on PCI
+   depends on DMI
+   depends on I2C_MLXCPLD
+   depends on I2C_MUX_REG
+   select HWMON
+   select PMBUS
+   select LM75
+   select NEW_LEDS
+   select LEDS_CLASS
+   select LEDS_TRIGGERS
+   select LEDS_TRIGGER_TIMER
+   select LEDS_MLXCPLD
+   ---help---
+ This option enables system support for the Mellanox Technologies
+ platform.
+
+ Say Y here if you are building a kernel for Mellanox system.
+
+ Otherwise, say N.
+
 config AMD_NB
def_bool y
depends on CPU_SUP_AMD && PCI
diff --git a/arch/x86/platform/Makefile b/arch/x86/platform/Makefile
index 184842e..3c3c19e 100644
--- a/arch/x86/platform/Makefile
+++ b/arch/x86/platform/Makefile
@@ -8,6 +8,7 @@ obj-y   += iris/
 obj-y  += intel/
 obj-y  += intel-mid/
 obj-y  += intel-quark/
+obj-y  += mellanox/
 obj-y  += olpc/
 obj-y  += scx200/
 obj-y  += sfi/
diff --git a/arch/x86/platform/mellanox/Makefile 
b/arch/x86/platform/mellanox/Makefile
new file mode 100644
index 000..f43c931
--- /dev/null
+++ b/arch/x86/platform/mellanox/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_MLX_PLATFORM) += mlx-platform.o
diff --git a/arch/x86/platform/mellanox/mlx-platform.c 
b/arch/x86/platform/mellanox/mlx-platform.c
new file mode 100644
index 000..02afa89
--- /dev/null
+++ b/arch/x86/platform/mellanox/mlx-platform.c
@@ -0,0 +1,501 @@
+/*
+ * arch/x86/platform/mellanox/mlx-platform.c
+ * Copyright (c) 2016 Mellanox Technologies. All rights reserved.
+ * Copyright (c) 2016 Vadim Pasternak 
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. Neither the names of the copyright holders nor the names of its
+ *contributors may be used to endorse or promote products derived from
+ *this software without specific prior written permission.
+ *
+ * Alternatively, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") version 2 as published by the Free
+ * Software Foundation.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) 

Re: [patch v1] x86/platform/mellanox: introduce support for Mellanox systems platform

[Guenter Roeck]

On 09/11/2016 11:29 PM, vad...@mellanox.com wrote:

From: Vadim Pasternak 

Enable system support for the Mellanox Technologies platform, which
provides support for the next Mellanox basic systems: "msx6710",
"msx6720", "msb7700", "msn2700", "msx1410", "msn2410", "msb7800",
"msn2740", "msn2100" and also various number of derivative systems from
the above basic types.

The Kconfig currently controlling compilation of this code is:
arch/x86/platform:config MLX_PLATFORM
arch/x86/platform:  tristate "Mellanox Technologies platform support"

Signed-off-by: Vadim Pasternak 
---
 MAINTAINERS   |   7 +
 arch/x86/Kconfig  |  23 ++
 arch/x86/platform/Makefile|   1 +
 arch/x86/platform/mellanox/Makefile   |   1 +
 arch/x86/platform/mellanox/mlx-platform.c | 501 ++
 5 files changed, 533 insertions(+)
 create mode 100644 arch/x86/platform/mellanox/Makefile
 create mode 100644 arch/x86/platform/mellanox/mlx-platform.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 4705c94..8a675de 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7664,6 +7664,13 @@ W:   http://www.mellanox.com
 Q: http://patchwork.ozlabs.org/project/netdev/list/
 F: drivers/net/ethernet/mellanox/mlxsw/

+MELLANOX PLATFORM DRIVER
+M:  Vadim Pasternak 
+L:  platform-driver-...@vger.kernel.org
+S:  Supported
+W:  http://www.mellanox.com
+F:  arch/x86/platform/mellanox/mlx-platform.c
+
 SOFT-ROCE DRIVER (rxe)
 M: Moni Shoua 
 L: linux-r...@vger.kernel.org
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index c580d8c..cc7efdd9 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2631,6 +2631,29 @@ config TS5500

 endif # X86_32

+config MLX_PLATFORM
+   tristate "Mellanox Technologies platform support"
+   depends on X86_64
+   depends on PCI
+   depends on DMI
+   depends on I2C_MLXCPLD
+   depends on I2C_MUX_REG
+   select HWMON
+   select PMBUS
+   select LM75
+   select NEW_LEDS
+   select LEDS_CLASS
+   select LEDS_TRIGGERS
+   select LEDS_TRIGGER_TIMER
+   select LEDS_MLXCPLD
+   ---help---
+ This option enables system support for the Mellanox Technologies
+ platform.
+
+ Say Y here if you are building a kernel for Mellanox system.
+
+ Otherwise, say N.
+
 config AMD_NB
def_bool y
depends on CPU_SUP_AMD && PCI
diff --git a/arch/x86/platform/Makefile b/arch/x86/platform/Makefile
index 184842e..3c3c19e 100644
--- a/arch/x86/platform/Makefile
+++ b/arch/x86/platform/Makefile
@@ -8,6 +8,7 @@ obj-y   += iris/
 obj-y  += intel/
 obj-y  += intel-mid/
 obj-y  += intel-quark/
+obj-y  += mellanox/
 obj-y  += olpc/
 obj-y  += scx200/
 obj-y  += sfi/
diff --git a/arch/x86/platform/mellanox/Makefile 
b/arch/x86/platform/mellanox/Makefile
new file mode 100644
index 000..f43c931
--- /dev/null
+++ b/arch/x86/platform/mellanox/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_MLX_PLATFORM) += mlx-platform.o
diff --git a/arch/x86/platform/mellanox/mlx-platform.c 
b/arch/x86/platform/mellanox/mlx-platform.c
new file mode 100644
index 000..02afa89
--- /dev/null
+++ b/arch/x86/platform/mellanox/mlx-platform.c
@@ -0,0 +1,501 @@
+/*
+ * arch/x86/platform/mellanox/mlx-platform.c
+ * Copyright (c) 2016 Mellanox Technologies. All rights reserved.
+ * Copyright (c) 2016 Vadim Pasternak 
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. Neither the names of the copyright holders nor the names of its
+ *contributors may be used to endorse or promote products derived from
+ *this software without specific prior written permission.
+ *
+ * Alternatively, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") version 2 as published by the Free
+ * Software Foundation.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT 

Re: [PATCH V4] mm: Add sysfs interface to dump each node's zonelist information

[Anshuman Khandual]

On 09/09/2016 01:54 AM, Dave Hansen wrote:
> On 09/07/2016 07:46 PM, Anshuman Khandual wrote:
>> > after memory or node hot[un]plug is desirable. This change adds one
>> > new sysfs interface (/sys/devices/system/memory/system_zone_details)
>> > which will fetch and dump this information.
> Doesn't this violate the "one value per file" sysfs rule?  Does it
> belong in debugfs instead?

Yeah sure. Will make it a debugfs interface.

> 
> I also really question the need to dump kernel addresses out, filtered
> or not.  What's the point?

Hmm, thought it to be an additional information. But yes its additional
and can be dropped.

Re: [PATCH V4] mm: Add sysfs interface to dump each node's zonelist information

[Anshuman Khandual]

On 09/09/2016 01:54 AM, Dave Hansen wrote:
> On 09/07/2016 07:46 PM, Anshuman Khandual wrote:
>> > after memory or node hot[un]plug is desirable. This change adds one
>> > new sysfs interface (/sys/devices/system/memory/system_zone_details)
>> > which will fetch and dump this information.
> Doesn't this violate the "one value per file" sysfs rule?  Does it
> belong in debugfs instead?

Yeah sure. Will make it a debugfs interface.

> 
> I also really question the need to dump kernel addresses out, filtered
> or not.  What's the point?

Hmm, thought it to be an additional information. But yes its additional
and can be dropped.

Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)

[Christoph Hellwig]

On Thu, Sep 08, 2016 at 04:56:36PM -0600, Ross Zwisler wrote:
> I think this goes back to our previous discussion about support for the PMEM
> programming model.  Really I think what NVML needs isn't a way to tell if it
> is getting a DAX mapping, but whether it is getting a DAX mapping on a
> filesystem that fully supports the PMEM programming model.  This of course is
> defined to be a filesystem where it can do all of its flushes from userspace
> safely and never call fsync/msync, and that allocations that happen in page
> faults will be synchronized to media before the page fault completes.

That's a an easy way to flag:  you will never get that from a Linux
filesystem, period.

NVML folks really need to stop taking crack and dreaming this could
happen.

Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)

[Christoph Hellwig]

On Thu, Sep 08, 2016 at 04:56:36PM -0600, Ross Zwisler wrote:
> I think this goes back to our previous discussion about support for the PMEM
> programming model.  Really I think what NVML needs isn't a way to tell if it
> is getting a DAX mapping, but whether it is getting a DAX mapping on a
> filesystem that fully supports the PMEM programming model.  This of course is
> defined to be a filesystem where it can do all of its flushes from userspace
> safely and never call fsync/msync, and that allocations that happen in page
> faults will be synchronized to media before the page fault completes.

That's a an easy way to flag:  you will never get that from a Linux
filesystem, period.

NVML folks really need to stop taking crack and dreaming this could
happen.

RE: [patch v1] x86/platform/mellanox: introduce support for Mellanox systems platform

[Vadim Pasternak]

> -Original Message-
> From: H. Peter Anvin [mailto:h...@zytor.com]
> Sent: Monday, September 12, 2016 7:42 AM
> To: Vadim Pasternak ; t...@linutronix.de
> Cc: mi...@redhat.com; da...@davemloft.net; ge...@linux-m68k.org;
> a...@linux-foundation.org; gre...@linuxfoundation.org;
> kv...@codeaurora.org; mche...@kernel.org; li...@roeck-us.net;
> x...@kernel.org; linux-kernel@vger.kernel.org; platform-driver-
> x...@vger.kernel.org; j...@resnulli.us
> Subject: Re: [patch v1] x86/platform/mellanox: introduce support for Mellanox
> systems platform
> 
> On September 11, 2016 11:29:58 PM PDT, vad...@mellanox.com wrote:
> >From: Vadim Pasternak 
> >
> >Enable system support for the Mellanox Technologies platform, which
> >provides support for the next Mellanox basic systems: "msx6710",
> >"msx6720", "msb7700", "msn2700", "msx1410", "msn2410", "msb7800",
> >"msn2740", "msn2100" and also various number of derivative systems from
> >the above basic types.
> >
> >The Kconfig currently controlling compilation of this code is:
> >arch/x86/platform:config MLX_PLATFORM
> >arch/x86/platform:  tristate "Mellanox Technologies platform
> >support"
> >
> >Signed-off-by: Vadim Pasternak 
> >---
> > MAINTAINERS   |   7 +
> > arch/x86/Kconfig  |  23 ++
> > arch/x86/platform/Makefile|   1 +
> > arch/x86/platform/mellanox/Makefile   |   1 +
> >arch/x86/platform/mellanox/mlx-platform.c | 501
> >++
> > 5 files changed, 533 insertions(+)
> > create mode 100644 arch/x86/platform/mellanox/Makefile
> > create mode 100644 arch/x86/platform/mellanox/mlx-platform.c
> >
> >diff --git a/MAINTAINERS b/MAINTAINERS
> >index 4705c94..8a675de 100644
> >--- a/MAINTAINERS
> >+++ b/MAINTAINERS
> >@@ -7664,6 +7664,13 @@ W:http://www.mellanox.com
> > Q:  http://patchwork.ozlabs.org/project/netdev/list/
> > F:  drivers/net/ethernet/mellanox/mlxsw/
> >
> >+MELLANOX PLATFORM DRIVER
> >+M:  Vadim Pasternak 
> >+L:  platform-driver-...@vger.kernel.org
> >+S:  Supported
> >+W:  http://www.mellanox.com
> >+F:  arch/x86/platform/mellanox/mlx-platform.c
> >+
> > SOFT-ROCE DRIVER (rxe)
> > M:  Moni Shoua 
> > L:  linux-r...@vger.kernel.org
> >diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index
> >c580d8c..cc7efdd9 100644
> >--- a/arch/x86/Kconfig
> >+++ b/arch/x86/Kconfig
> >@@ -2631,6 +2631,29 @@ config TS5500
> >
> > endif # X86_32
> >
> >+config MLX_PLATFORM
> >+tristate "Mellanox Technologies platform support"
> >+depends on X86_64
> >+depends on PCI
> >+depends on DMI
> >+depends on I2C_MLXCPLD
> >+depends on I2C_MUX_REG
> >+select HWMON
> >+select PMBUS
> >+select LM75
> >+select NEW_LEDS
> >+select LEDS_CLASS
> >+select LEDS_TRIGGERS
> >+select LEDS_TRIGGER_TIMER
> >+select LEDS_MLXCPLD
> >+---help---
> >+  This option enables system support for the Mellanox Technologies
> >+  platform.
> >+
> >+  Say Y here if you are building a kernel for Mellanox system.
> >+
> >+  Otherwise, say N.
> >+
> > config AMD_NB
> > def_bool y
> > depends on CPU_SUP_AMD && PCI
> >diff --git a/arch/x86/platform/Makefile b/arch/x86/platform/Makefile
> >index 184842e..3c3c19e 100644
> >--- a/arch/x86/platform/Makefile
> >+++ b/arch/x86/platform/Makefile
> >@@ -8,6 +8,7 @@ obj-y+= iris/
> > obj-y   += intel/
> > obj-y   += intel-mid/
> > obj-y   += intel-quark/
> >+obj-y   += mellanox/
> > obj-y   += olpc/
> > obj-y   += scx200/
> > obj-y   += sfi/
> >diff --git a/arch/x86/platform/mellanox/Makefile
> >b/arch/x86/platform/mellanox/Makefile
> >new file mode 100644
> >index 000..f43c931
> >--- /dev/null
> >+++ b/arch/x86/platform/mellanox/Makefile
> >@@ -0,0 +1 @@
> >+obj-$(CONFIG_MLX_PLATFORM)  += mlx-platform.o
> >diff --git a/arch/x86/platform/mellanox/mlx-platform.c
> >b/arch/x86/platform/mellanox/mlx-platform.c
> >new file mode 100644
> >index 000..02afa89
> >--- /dev/null
> >+++ b/arch/x86/platform/mellanox/mlx-platform.c
> >@@ -0,0 +1,501 @@
> >+/*
> >+ * arch/x86/platform/mellanox/mlx-platform.c
> >+ * Copyright (c) 2016 Mellanox Technologies. All rights reserved.
> >+ * Copyright (c) 2016 Vadim Pasternak 
> >+ *
> >+ * Redistribution and use in source and binary forms, with or without
> >+ * modification, are permitted provided that the following conditions
> >are met:
> >+ *
> >+ * 1. Redistributions of source code must retain the above copyright
> >+ *notice, this list of conditions and the following disclaimer.
> >+ * 2. Redistributions in binary form must reproduce the above
> >copyright
> >+ *notice, this list of conditions and the following disclaimer in
> >the
> >+ *documentation and/or other materials provided with the
> >distribution.
> >+ * 3. Neither the names of 

RE: [patch v1] x86/platform/mellanox: introduce support for Mellanox systems platform

[Vadim Pasternak]

> -Original Message-
> From: H. Peter Anvin [mailto:h...@zytor.com]
> Sent: Monday, September 12, 2016 7:42 AM
> To: Vadim Pasternak ; t...@linutronix.de
> Cc: mi...@redhat.com; da...@davemloft.net; ge...@linux-m68k.org;
> a...@linux-foundation.org; gre...@linuxfoundation.org;
> kv...@codeaurora.org; mche...@kernel.org; li...@roeck-us.net;
> x...@kernel.org; linux-kernel@vger.kernel.org; platform-driver-
> x...@vger.kernel.org; j...@resnulli.us
> Subject: Re: [patch v1] x86/platform/mellanox: introduce support for Mellanox
> systems platform
> 
> On September 11, 2016 11:29:58 PM PDT, vad...@mellanox.com wrote:
> >From: Vadim Pasternak 
> >
> >Enable system support for the Mellanox Technologies platform, which
> >provides support for the next Mellanox basic systems: "msx6710",
> >"msx6720", "msb7700", "msn2700", "msx1410", "msn2410", "msb7800",
> >"msn2740", "msn2100" and also various number of derivative systems from
> >the above basic types.
> >
> >The Kconfig currently controlling compilation of this code is:
> >arch/x86/platform:config MLX_PLATFORM
> >arch/x86/platform:  tristate "Mellanox Technologies platform
> >support"
> >
> >Signed-off-by: Vadim Pasternak 
> >---
> > MAINTAINERS   |   7 +
> > arch/x86/Kconfig  |  23 ++
> > arch/x86/platform/Makefile|   1 +
> > arch/x86/platform/mellanox/Makefile   |   1 +
> >arch/x86/platform/mellanox/mlx-platform.c | 501
> >++
> > 5 files changed, 533 insertions(+)
> > create mode 100644 arch/x86/platform/mellanox/Makefile
> > create mode 100644 arch/x86/platform/mellanox/mlx-platform.c
> >
> >diff --git a/MAINTAINERS b/MAINTAINERS
> >index 4705c94..8a675de 100644
> >--- a/MAINTAINERS
> >+++ b/MAINTAINERS
> >@@ -7664,6 +7664,13 @@ W:http://www.mellanox.com
> > Q:  http://patchwork.ozlabs.org/project/netdev/list/
> > F:  drivers/net/ethernet/mellanox/mlxsw/
> >
> >+MELLANOX PLATFORM DRIVER
> >+M:  Vadim Pasternak 
> >+L:  platform-driver-...@vger.kernel.org
> >+S:  Supported
> >+W:  http://www.mellanox.com
> >+F:  arch/x86/platform/mellanox/mlx-platform.c
> >+
> > SOFT-ROCE DRIVER (rxe)
> > M:  Moni Shoua 
> > L:  linux-r...@vger.kernel.org
> >diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index
> >c580d8c..cc7efdd9 100644
> >--- a/arch/x86/Kconfig
> >+++ b/arch/x86/Kconfig
> >@@ -2631,6 +2631,29 @@ config TS5500
> >
> > endif # X86_32
> >
> >+config MLX_PLATFORM
> >+tristate "Mellanox Technologies platform support"
> >+depends on X86_64
> >+depends on PCI
> >+depends on DMI
> >+depends on I2C_MLXCPLD
> >+depends on I2C_MUX_REG
> >+select HWMON
> >+select PMBUS
> >+select LM75
> >+select NEW_LEDS
> >+select LEDS_CLASS
> >+select LEDS_TRIGGERS
> >+select LEDS_TRIGGER_TIMER
> >+select LEDS_MLXCPLD
> >+---help---
> >+  This option enables system support for the Mellanox Technologies
> >+  platform.
> >+
> >+  Say Y here if you are building a kernel for Mellanox system.
> >+
> >+  Otherwise, say N.
> >+
> > config AMD_NB
> > def_bool y
> > depends on CPU_SUP_AMD && PCI
> >diff --git a/arch/x86/platform/Makefile b/arch/x86/platform/Makefile
> >index 184842e..3c3c19e 100644
> >--- a/arch/x86/platform/Makefile
> >+++ b/arch/x86/platform/Makefile
> >@@ -8,6 +8,7 @@ obj-y+= iris/
> > obj-y   += intel/
> > obj-y   += intel-mid/
> > obj-y   += intel-quark/
> >+obj-y   += mellanox/
> > obj-y   += olpc/
> > obj-y   += scx200/
> > obj-y   += sfi/
> >diff --git a/arch/x86/platform/mellanox/Makefile
> >b/arch/x86/platform/mellanox/Makefile
> >new file mode 100644
> >index 000..f43c931
> >--- /dev/null
> >+++ b/arch/x86/platform/mellanox/Makefile
> >@@ -0,0 +1 @@
> >+obj-$(CONFIG_MLX_PLATFORM)  += mlx-platform.o
> >diff --git a/arch/x86/platform/mellanox/mlx-platform.c
> >b/arch/x86/platform/mellanox/mlx-platform.c
> >new file mode 100644
> >index 000..02afa89
> >--- /dev/null
> >+++ b/arch/x86/platform/mellanox/mlx-platform.c
> >@@ -0,0 +1,501 @@
> >+/*
> >+ * arch/x86/platform/mellanox/mlx-platform.c
> >+ * Copyright (c) 2016 Mellanox Technologies. All rights reserved.
> >+ * Copyright (c) 2016 Vadim Pasternak 
> >+ *
> >+ * Redistribution and use in source and binary forms, with or without
> >+ * modification, are permitted provided that the following conditions
> >are met:
> >+ *
> >+ * 1. Redistributions of source code must retain the above copyright
> >+ *notice, this list of conditions and the following disclaimer.
> >+ * 2. Redistributions in binary form must reproduce the above
> >copyright
> >+ *notice, this list of conditions and the following disclaimer in
> >the
> >+ *documentation and/or other materials provided with the
> >distribution.
> >+ * 3. Neither the names of the copyright holders nor the names of its
> >+ *contributors may be used to endorse or promote products derived
> >from

Re: [PATCH V4] mm: Add sysfs interface to dump each node's zonelist information

[Anshuman Khandual]

On 09/09/2016 07:06 PM, Michal Hocko wrote:
> On Thu 08-09-16 08:16:58, Anshuman Khandual wrote:
>> > Each individual node in the system has a ZONELIST_FALLBACK zonelist
>> > and a ZONELIST_NOFALLBACK zonelist. These zonelists decide fallback
>> > order of zones during memory allocations. Sometimes it helps to dump
>> > these zonelists to see the priority order of various zones in them.
>> > 
>> > Particularly platforms which support memory hotplug into previously
>> > non existing zones (at boot), this interface helps in visualizing
>> > which all zonelists of the system at what priority level, the new
>> > hot added memory ends up in. POWER is such a platform where all the
>> > memory detected during boot time remains with ZONE_DMA for good but
>> > then hot plug process can actually get new memory into ZONE_MOVABLE.
>> > So having a way to get the snapshot of the zonelists on the system
>> > after memory or node hot[un]plug is desirable. This change adds one
>> > new sysfs interface (/sys/devices/system/memory/system_zone_details)
>> > which will fetch and dump this information.
> I am still not sure I understand why this is helpful and who is the
> consumer for this interface and how it will benefit from the
> information. Dave (who doesn't seem to be on the CC list re-added) had
> another objection that this breaks one-value-per-file rule for sysfs
> files.

It helps in understanding the relative priority of each memory zone of the
system during various allocation scenarios. Its particularly helpful after
hotplug/unplug of additional memory into previously non existing zone on
a node.

> 
> This all smells like a debugging feature to me and so it should go into
> debugfs.

Sure, will make it a debugfs interface.

Re: [PATCH V4] mm: Add sysfs interface to dump each node's zonelist information

[Anshuman Khandual]

On 09/09/2016 07:06 PM, Michal Hocko wrote:
> On Thu 08-09-16 08:16:58, Anshuman Khandual wrote:
>> > Each individual node in the system has a ZONELIST_FALLBACK zonelist
>> > and a ZONELIST_NOFALLBACK zonelist. These zonelists decide fallback
>> > order of zones during memory allocations. Sometimes it helps to dump
>> > these zonelists to see the priority order of various zones in them.
>> > 
>> > Particularly platforms which support memory hotplug into previously
>> > non existing zones (at boot), this interface helps in visualizing
>> > which all zonelists of the system at what priority level, the new
>> > hot added memory ends up in. POWER is such a platform where all the
>> > memory detected during boot time remains with ZONE_DMA for good but
>> > then hot plug process can actually get new memory into ZONE_MOVABLE.
>> > So having a way to get the snapshot of the zonelists on the system
>> > after memory or node hot[un]plug is desirable. This change adds one
>> > new sysfs interface (/sys/devices/system/memory/system_zone_details)
>> > which will fetch and dump this information.
> I am still not sure I understand why this is helpful and who is the
> consumer for this interface and how it will benefit from the
> information. Dave (who doesn't seem to be on the CC list re-added) had
> another objection that this breaks one-value-per-file rule for sysfs
> files.

It helps in understanding the relative priority of each memory zone of the
system during various allocation scenarios. Its particularly helpful after
hotplug/unplug of additional memory into previously non existing zone on
a node.

> 
> This all smells like a debugging feature to me and so it should go into
> debugfs.

Sure, will make it a debugfs interface.

Use of schedule() function while holding a lock in ql4_nx.c

[Vaishali Thakkar]

Hello,

I was wondering about the call to schedule in function qla4_82xx_crb_win_lock 
for driver
drivers/scsi/qla4xxx/ql4_nx.c. It is called in 2 functions [qla4_82xx_rd_32 and
qla4_82xx_wr_32] while holding a write_lock_irqsave. Normally we avoid using 
sleeping
functions while holding a lock.

Is there some reason that I am overlooking? Why it is OK in this case? Are we 
using
schedule() here intentionally?

Thank you.


-- 
Vaishali

Use of schedule() function while holding a lock in ql4_nx.c

[Vaishali Thakkar]

Hello,

I was wondering about the call to schedule in function qla4_82xx_crb_win_lock 
for driver
drivers/scsi/qla4xxx/ql4_nx.c. It is called in 2 functions [qla4_82xx_rd_32 and
qla4_82xx_wr_32] while holding a write_lock_irqsave. Normally we avoid using 
sleeping
functions while holding a lock.

Is there some reason that I am overlooking? Why it is OK in this case? Are we 
using
schedule() here intentionally?

Thank you.


-- 
Vaishali

Re: [PATCH] logfs: remove from tree

[Christoph Hellwig]

On Mon, Sep 12, 2016 at 11:53:19AM +1000, Dave Chinner wrote:
> Wasn't the lib/btree.c implementation introduced with and only used
> by logfs? Should that go as well?

The qla2xxx SCSI target driver also uses the btree library.

Re: [PATCH] logfs: remove from tree

[Christoph Hellwig]

On Mon, Sep 12, 2016 at 11:53:19AM +1000, Dave Chinner wrote:
> Wasn't the lib/btree.c implementation introduced with and only used
> by logfs? Should that go as well?

The qla2xxx SCSI target driver also uses the btree library.

linux-next: build failure after merge of the v4l-dvb tree

[Stephen Rothwell]

Hi all,

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

drivers/media/platform/soc_camera/built-in.o:(.opd+0x678): multiple definition 
of `soc_mbus_config_compatible'
drivers/media/platform/soc_camera/soc_mediabus.o:(.opd+0x78): first defined here
drivers/media/platform/soc_camera/built-in.o:(.opd+0x630): multiple definition 
of `soc_mbus_image_size'
drivers/media/platform/soc_camera/soc_mediabus.o:(.opd+0x30): first defined here
drivers/media/platform/soc_camera/built-in.o:(.opd+0x600): multiple definition 
of `soc_mbus_samples_per_pixel'
drivers/media/platform/soc_camera/soc_mediabus.o:(.opd+0x0): first defined here
drivers/media/platform/soc_camera/built-in.o: In function 
`.soc_mbus_bytes_per_line':
(.text+0x4d20): multiple definition of `.soc_mbus_bytes_per_line'
drivers/media/platform/soc_camera/soc_mediabus.o:(.text+0x120): first defined 
here
drivers/media/platform/soc_camera/built-in.o: In function 
`.soc_mbus_get_fmtdesc':
(.text+0x4f90): multiple definition of `.soc_mbus_get_fmtdesc'
drivers/media/platform/soc_camera/soc_mediabus.o:(.text+0x390): first defined 
here
drivers/media/platform/soc_camera/built-in.o:(.opd+0x660): multiple definition 
of `soc_mbus_get_fmtdesc'
drivers/media/platform/soc_camera/soc_mediabus.o:(.opd+0x60): first defined here
drivers/media/platform/soc_camera/built-in.o: In function 
`.soc_mbus_image_size':
(.text+0x4e10): multiple definition of `.soc_mbus_image_size'
drivers/media/platform/soc_camera/soc_mediabus.o:(.text+0x210): first defined 
here
drivers/media/platform/soc_camera/built-in.o: In function 
`.soc_mbus_samples_per_pixel':
(.text+0x4c00): multiple definition of `.soc_mbus_samples_per_pixel'
drivers/media/platform/soc_camera/soc_mediabus.o:(.text+0x0): first defined here
drivers/media/platform/soc_camera/built-in.o: In function 
`.soc_mbus_config_compatible':
(.text+0x5030): multiple definition of `.soc_mbus_config_compatible'
drivers/media/platform/soc_camera/soc_mediabus.o:(.text+0x430): first defined 
here
drivers/media/platform/soc_camera/built-in.o: In function 
`.soc_mbus_find_fmtdesc':
(.text+0x4ec0): multiple definition of `.soc_mbus_find_fmtdesc'
drivers/media/platform/soc_camera/soc_mediabus.o:(.text+0x2c0): first defined 
here
drivers/media/platform/soc_camera/built-in.o:(.opd+0x648): multiple definition 
of `soc_mbus_find_fmtdesc'
drivers/media/platform/soc_camera/soc_mediabus.o:(.opd+0x48): first defined here
drivers/media/platform/soc_camera/built-in.o:(.opd+0x618): multiple definition 
of `soc_mbus_bytes_per_line'
drivers/media/platform/soc_camera/soc_mediabus.o:(.opd+0x18): first defined here

Caused by commit

  4bb738f228b3 ("[media] media: platform: pxa_camera: move pxa_camera out of 
soc_camera")

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

linux-next: build failure after merge of the v4l-dvb tree

[Stephen Rothwell]

Hi all,

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

drivers/media/platform/soc_camera/built-in.o:(.opd+0x678): multiple definition 
of `soc_mbus_config_compatible'
drivers/media/platform/soc_camera/soc_mediabus.o:(.opd+0x78): first defined here
drivers/media/platform/soc_camera/built-in.o:(.opd+0x630): multiple definition 
of `soc_mbus_image_size'
drivers/media/platform/soc_camera/soc_mediabus.o:(.opd+0x30): first defined here
drivers/media/platform/soc_camera/built-in.o:(.opd+0x600): multiple definition 
of `soc_mbus_samples_per_pixel'
drivers/media/platform/soc_camera/soc_mediabus.o:(.opd+0x0): first defined here
drivers/media/platform/soc_camera/built-in.o: In function 
`.soc_mbus_bytes_per_line':
(.text+0x4d20): multiple definition of `.soc_mbus_bytes_per_line'
drivers/media/platform/soc_camera/soc_mediabus.o:(.text+0x120): first defined 
here
drivers/media/platform/soc_camera/built-in.o: In function 
`.soc_mbus_get_fmtdesc':
(.text+0x4f90): multiple definition of `.soc_mbus_get_fmtdesc'
drivers/media/platform/soc_camera/soc_mediabus.o:(.text+0x390): first defined 
here
drivers/media/platform/soc_camera/built-in.o:(.opd+0x660): multiple definition 
of `soc_mbus_get_fmtdesc'
drivers/media/platform/soc_camera/soc_mediabus.o:(.opd+0x60): first defined here
drivers/media/platform/soc_camera/built-in.o: In function 
`.soc_mbus_image_size':
(.text+0x4e10): multiple definition of `.soc_mbus_image_size'
drivers/media/platform/soc_camera/soc_mediabus.o:(.text+0x210): first defined 
here
drivers/media/platform/soc_camera/built-in.o: In function 
`.soc_mbus_samples_per_pixel':
(.text+0x4c00): multiple definition of `.soc_mbus_samples_per_pixel'
drivers/media/platform/soc_camera/soc_mediabus.o:(.text+0x0): first defined here
drivers/media/platform/soc_camera/built-in.o: In function 
`.soc_mbus_config_compatible':
(.text+0x5030): multiple definition of `.soc_mbus_config_compatible'
drivers/media/platform/soc_camera/soc_mediabus.o:(.text+0x430): first defined 
here
drivers/media/platform/soc_camera/built-in.o: In function 
`.soc_mbus_find_fmtdesc':
(.text+0x4ec0): multiple definition of `.soc_mbus_find_fmtdesc'
drivers/media/platform/soc_camera/soc_mediabus.o:(.text+0x2c0): first defined 
here
drivers/media/platform/soc_camera/built-in.o:(.opd+0x648): multiple definition 
of `soc_mbus_find_fmtdesc'
drivers/media/platform/soc_camera/soc_mediabus.o:(.opd+0x48): first defined here
drivers/media/platform/soc_camera/built-in.o:(.opd+0x618): multiple definition 
of `soc_mbus_bytes_per_line'
drivers/media/platform/soc_camera/soc_mediabus.o:(.opd+0x18): first defined here

Caused by commit

  4bb738f228b3 ("[media] media: platform: pxa_camera: move pxa_camera out of 
soc_camera")

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell

Re: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller

[Leon Romanovsky]

On Sun, Sep 11, 2016 at 11:52:35AM -0600, Jason Gunthorpe wrote:
> On Sun, Sep 11, 2016 at 07:24:45PM +0200, Christoph Hellwig wrote:
> > > > > I've posted some initial work toward a) a while ago, and once we
> > >
> > > Did it get merged? Do you have a pointer?
> >
> > http://www.spinics.net/lists/linux-rdma/msg31958.html
>
> Right, I remember that. Certainly the right direction
>
> > > However, everything under verbs is not straightforward. The files in
> > > userspace are not copies...
> > >
> > > user:
> > >
> > > struct ibv_query_device {
> > >__u32 command;
> > >__u16 in_words;
> > >__u16 out_words;
> > >__u64 response;
> > >__u64 driver_data[0];
> > > };
> > >
> > > kernel:
> > >
> > > struct ib_uverbs_query_device {
> > > __u64 response;
> > > __u64 driver_data[0];
> > > };
> >
> > We'll obviously need different strutures for the libibvers API
> > and the kernel interface in this case, and we'll need to figure out
> > how to properly translate them.  I think a cast, plus compile time
> > type checking ala BUILD_BUG_ON is the way to go.
>
> I'm not sure I follow, which would I cast?
>
> BUILD_BUG_ON(sizeof(ibv_query_device) == sizeof(ib_uverbs_cmd_hdr) +
>  sizeof(ib_uverbs_query_device))
>
> ?
>
> > > I'm thinking the best way forward might be to use a script and
> > > transform userspace into:
> > >
> > > struct ibv_query_device {
> > >   struct ib_uverbs_cmd_hdr hdr;
> > >   struct ib_uverbs_query_device cmd;
> > > };
> >
> > That would break the users of the interface.
>
> Sorry, I mean doing this inside rdma-plumbing. Since the change is ABI
> identical the modified libibverbs would still be binary compatible
> with all providers but not source compatible. Since all kernel
> supported providers are in rdma-plumbing we can add the '.cmd.' at the
> same time.
>
> The kernel uapi header would stay the same.
>
> > However automatically generating the user ABI from the kernel one
> > might still be a good idea in the long run.
>
> My preference would be to try and use the kernel headers directly.

I thought the same, especially after realizing that they are almost
copy/paste from the vendor *-abi.h files.

>
> Jason


signature.asc
Description: PGP signature

Re: [PATCHv12 1/3] rdmacg: Added rdma cgroup controller

[Leon Romanovsky]

On Sun, Sep 11, 2016 at 11:52:35AM -0600, Jason Gunthorpe wrote:
> On Sun, Sep 11, 2016 at 07:24:45PM +0200, Christoph Hellwig wrote:
> > > > > I've posted some initial work toward a) a while ago, and once we
> > >
> > > Did it get merged? Do you have a pointer?
> >
> > http://www.spinics.net/lists/linux-rdma/msg31958.html
>
> Right, I remember that. Certainly the right direction
>
> > > However, everything under verbs is not straightforward. The files in
> > > userspace are not copies...
> > >
> > > user:
> > >
> > > struct ibv_query_device {
> > >__u32 command;
> > >__u16 in_words;
> > >__u16 out_words;
> > >__u64 response;
> > >__u64 driver_data[0];
> > > };
> > >
> > > kernel:
> > >
> > > struct ib_uverbs_query_device {
> > > __u64 response;
> > > __u64 driver_data[0];
> > > };
> >
> > We'll obviously need different strutures for the libibvers API
> > and the kernel interface in this case, and we'll need to figure out
> > how to properly translate them.  I think a cast, plus compile time
> > type checking ala BUILD_BUG_ON is the way to go.
>
> I'm not sure I follow, which would I cast?
>
> BUILD_BUG_ON(sizeof(ibv_query_device) == sizeof(ib_uverbs_cmd_hdr) +
>  sizeof(ib_uverbs_query_device))
>
> ?
>
> > > I'm thinking the best way forward might be to use a script and
> > > transform userspace into:
> > >
> > > struct ibv_query_device {
> > >   struct ib_uverbs_cmd_hdr hdr;
> > >   struct ib_uverbs_query_device cmd;
> > > };
> >
> > That would break the users of the interface.
>
> Sorry, I mean doing this inside rdma-plumbing. Since the change is ABI
> identical the modified libibverbs would still be binary compatible
> with all providers but not source compatible. Since all kernel
> supported providers are in rdma-plumbing we can add the '.cmd.' at the
> same time.
>
> The kernel uapi header would stay the same.
>
> > However automatically generating the user ABI from the kernel one
> > might still be a good idea in the long run.
>
> My preference would be to try and use the kernel headers directly.

I thought the same, especially after realizing that they are almost
copy/paste from the vendor *-abi.h files.

>
> Jason


signature.asc
Description: PGP signature

Re: [PATCH 07/26] net/mlx4_core: constify local structures

[Leon Romanovsky]

On Sun, Sep 11, 2016 at 03:05:49PM +0200, Julia Lawall wrote:
> For structure types defined in the same file or local header files, find
> top-level static structure declarations that have the following
> properties:
> 1. Never reassigned.
> 2. Address never taken
> 3. Not passed to a top-level macro call
> 4. No pointer or array-typed field passed to a function or stored in a
> variable.
> Declare structures having all of these properties as const.
>
> Done using Coccinelle.
> Based on a suggestion by Joe Perches .
>
> Signed-off-by: Julia Lawall 

Thanks,
Reviewed-by: Leon Romanovsky 


signature.asc
Description: PGP signature

Re: [PATCH 07/26] net/mlx4_core: constify local structures

[Leon Romanovsky]

On Sun, Sep 11, 2016 at 03:05:49PM +0200, Julia Lawall wrote:
> For structure types defined in the same file or local header files, find
> top-level static structure declarations that have the following
> properties:
> 1. Never reassigned.
> 2. Address never taken
> 3. Not passed to a top-level macro call
> 4. No pointer or array-typed field passed to a function or stored in a
> variable.
> Declare structures having all of these properties as const.
>
> Done using Coccinelle.
> Based on a suggestion by Joe Perches .
>
> Signed-off-by: Julia Lawall 

Thanks,
Reviewed-by: Leon Romanovsky 


signature.asc
Description: PGP signature

Re: [PATCH] IB/rdmavt: free the userspace memory region with kfree instead of vfree

[Leon Romanovsky]

On Fri, Sep 09, 2016 at 08:15:37AM +0100, Colin King wrote:
> From: Colin Ian King 
>
> The userspace memory region 'mr' is allocated with kzalloc in
> __rvt_alloc_mr  however it is incorrectly being freed with vfree in
> __rvt_free_mr. Fix this by using kfree to free it.
>
> Signed-off-by: Colin Ian King 

Thanks,
Reviewed-by: Leon Romanovsky 

> ---
>  drivers/infiniband/sw/rdmavt/mr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/sw/rdmavt/mr.c 
> b/drivers/infiniband/sw/rdmavt/mr.c
> index 80c4b6b..46b6497 100644
> --- a/drivers/infiniband/sw/rdmavt/mr.c
> +++ b/drivers/infiniband/sw/rdmavt/mr.c
> @@ -294,7 +294,7 @@ static void __rvt_free_mr(struct rvt_mr *mr)
>  {
>   rvt_deinit_mregion(>mr);
>   rvt_free_lkey(>mr);
> - vfree(mr);
> + kfree(mr);
>  }
>
>  /**
> --
> 2.9.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


signature.asc
Description: PGP signature

Re: [PATCH] IB/rdmavt: free the userspace memory region with kfree instead of vfree

[Leon Romanovsky]

On Fri, Sep 09, 2016 at 08:15:37AM +0100, Colin King wrote:
> From: Colin Ian King 
>
> The userspace memory region 'mr' is allocated with kzalloc in
> __rvt_alloc_mr  however it is incorrectly being freed with vfree in
> __rvt_free_mr. Fix this by using kfree to free it.
>
> Signed-off-by: Colin Ian King 

Thanks,
Reviewed-by: Leon Romanovsky 

> ---
>  drivers/infiniband/sw/rdmavt/mr.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/sw/rdmavt/mr.c 
> b/drivers/infiniband/sw/rdmavt/mr.c
> index 80c4b6b..46b6497 100644
> --- a/drivers/infiniband/sw/rdmavt/mr.c
> +++ b/drivers/infiniband/sw/rdmavt/mr.c
> @@ -294,7 +294,7 @@ static void __rvt_free_mr(struct rvt_mr *mr)
>  {
>   rvt_deinit_mregion(>mr);
>   rvt_free_lkey(>mr);
> - vfree(mr);
> + kfree(mr);
>  }
>
>  /**
> --
> 2.9.3
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


signature.asc
Description: PGP signature

Re: [PATCH] drivers/edac: NO_IRQ removal from powerpc-only drivers

[Michael Ellerman]

Borislav Petkov  writes:

> On Sat, Sep 10, 2016 at 07:57:08PM +1000, Michael Ellerman wrote:
>> We'd like to eventually remove NO_IRQ on powerpc, so remove usages of it
>> from powerpc-only drivers.
>> 
>> Signed-off-by: Michael Ellerman 
>> ---
>>  drivers/edac/mpc85xx_edac.c | 6 +++---
>>  drivers/edac/mv64x60_edac.c | 8 
>>  drivers/edac/ppc4xx_edac.c  | 6 +++---
>>  3 files changed, 10 insertions(+), 10 deletions(-)
>> 
>> diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
>> index ca63d0da8889..e12b8e166a53 100644
>> --- a/drivers/edac/mpc85xx_edac.c
>> +++ b/drivers/edac/mpc85xx_edac.c
>> @@ -267,7 +267,7 @@ static int mpc85xx_pci_err_probe(struct platform_device 
>> *op)
>>  
>>  pdata = pci->pvt_info;
>>  pdata->name = "mpc85xx_pci_err";
>> -pdata->irq = NO_IRQ;
>> +pdata->irq = 0;
>>  
>>  plat_data = op->dev.platform_data;
>>  if (!plat_data) {
>
> So all of those pdata structs come from kzalloc() so you don't really
> have to assign to 0 - simply kill the line.

OK.

>> @@ -1058,7 +1058,7 @@ static int mpc85xx_mc_err_probe(struct platform_device 
>> *op)
>>  
>>  pdata = mci->pvt_info;
>>  pdata->name = "mpc85xx_mc_err";
>> -pdata->irq = NO_IRQ;
>> +pdata->irq = 0;
>>  mci->pdev = >dev;
>>  pdata->edac_idx = edac_mc_idx++;
>>  dev_set_drvdata(mci->pdev, mci);
>
> That part went into drivers/edac/fsl_ddr_edac.c which is only the
> freescale memory controller being shared between ARM and PPC, see
>
> http://git.kernel.org/cgit/linux/kernel/git/bp/bp.git/log/?h=for-next
>
> But that shouldn't change the issue wrt ->irq as now it is implicitly 0.

Ah OK.

NO_IRQ is -1 on ARM (or at least it can be?), see arch/arm/include/asm/irq.h.

So I'll leave that one alone for now.

> IOW, you can drop this hunk.
>
> Please send v2 against the above branch or linux-next.

OK will do.

cheers

Re: [PATCH] drivers/edac: NO_IRQ removal from powerpc-only drivers

[Michael Ellerman]

Borislav Petkov  writes:

> On Sat, Sep 10, 2016 at 07:57:08PM +1000, Michael Ellerman wrote:
>> We'd like to eventually remove NO_IRQ on powerpc, so remove usages of it
>> from powerpc-only drivers.
>> 
>> Signed-off-by: Michael Ellerman 
>> ---
>>  drivers/edac/mpc85xx_edac.c | 6 +++---
>>  drivers/edac/mv64x60_edac.c | 8 
>>  drivers/edac/ppc4xx_edac.c  | 6 +++---
>>  3 files changed, 10 insertions(+), 10 deletions(-)
>> 
>> diff --git a/drivers/edac/mpc85xx_edac.c b/drivers/edac/mpc85xx_edac.c
>> index ca63d0da8889..e12b8e166a53 100644
>> --- a/drivers/edac/mpc85xx_edac.c
>> +++ b/drivers/edac/mpc85xx_edac.c
>> @@ -267,7 +267,7 @@ static int mpc85xx_pci_err_probe(struct platform_device 
>> *op)
>>  
>>  pdata = pci->pvt_info;
>>  pdata->name = "mpc85xx_pci_err";
>> -pdata->irq = NO_IRQ;
>> +pdata->irq = 0;
>>  
>>  plat_data = op->dev.platform_data;
>>  if (!plat_data) {
>
> So all of those pdata structs come from kzalloc() so you don't really
> have to assign to 0 - simply kill the line.

OK.

>> @@ -1058,7 +1058,7 @@ static int mpc85xx_mc_err_probe(struct platform_device 
>> *op)
>>  
>>  pdata = mci->pvt_info;
>>  pdata->name = "mpc85xx_mc_err";
>> -pdata->irq = NO_IRQ;
>> +pdata->irq = 0;
>>  mci->pdev = >dev;
>>  pdata->edac_idx = edac_mc_idx++;
>>  dev_set_drvdata(mci->pdev, mci);
>
> That part went into drivers/edac/fsl_ddr_edac.c which is only the
> freescale memory controller being shared between ARM and PPC, see
>
> http://git.kernel.org/cgit/linux/kernel/git/bp/bp.git/log/?h=for-next
>
> But that shouldn't change the issue wrt ->irq as now it is implicitly 0.

Ah OK.

NO_IRQ is -1 on ARM (or at least it can be?), see arch/arm/include/asm/irq.h.

So I'll leave that one alone for now.

> IOW, you can drop this hunk.
>
> Please send v2 against the above branch or linux-next.

OK will do.

cheers

Re: [patch v1] x86/platform/mellanox: introduce support for Mellanox systems platform

[H. Peter Anvin]

On September 11, 2016 11:29:58 PM PDT, vad...@mellanox.com wrote:
>From: Vadim Pasternak 
>
>Enable system support for the Mellanox Technologies platform, which
>provides support for the next Mellanox basic systems: "msx6710",
>"msx6720", "msb7700", "msn2700", "msx1410", "msn2410", "msb7800",
>"msn2740", "msn2100" and also various number of derivative systems from
>the above basic types.
>
>The Kconfig currently controlling compilation of this code is:
>arch/x86/platform:config MLX_PLATFORM
>arch/x86/platform:  tristate "Mellanox Technologies platform
>support"
>
>Signed-off-by: Vadim Pasternak 
>---
> MAINTAINERS   |   7 +
> arch/x86/Kconfig  |  23 ++
> arch/x86/platform/Makefile|   1 +
> arch/x86/platform/mellanox/Makefile   |   1 +
>arch/x86/platform/mellanox/mlx-platform.c | 501
>++
> 5 files changed, 533 insertions(+)
> create mode 100644 arch/x86/platform/mellanox/Makefile
> create mode 100644 arch/x86/platform/mellanox/mlx-platform.c
>
>diff --git a/MAINTAINERS b/MAINTAINERS
>index 4705c94..8a675de 100644
>--- a/MAINTAINERS
>+++ b/MAINTAINERS
>@@ -7664,6 +7664,13 @@ W:  http://www.mellanox.com
> Q:http://patchwork.ozlabs.org/project/netdev/list/
> F:drivers/net/ethernet/mellanox/mlxsw/
> 
>+MELLANOX PLATFORM DRIVER
>+M:  Vadim Pasternak 
>+L:  platform-driver-...@vger.kernel.org
>+S:  Supported
>+W:  http://www.mellanox.com
>+F:  arch/x86/platform/mellanox/mlx-platform.c
>+
> SOFT-ROCE DRIVER (rxe)
> M:Moni Shoua 
> L:linux-r...@vger.kernel.org
>diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>index c580d8c..cc7efdd9 100644
>--- a/arch/x86/Kconfig
>+++ b/arch/x86/Kconfig
>@@ -2631,6 +2631,29 @@ config TS5500
> 
> endif # X86_32
> 
>+config MLX_PLATFORM
>+  tristate "Mellanox Technologies platform support"
>+  depends on X86_64
>+  depends on PCI
>+  depends on DMI
>+  depends on I2C_MLXCPLD
>+  depends on I2C_MUX_REG
>+  select HWMON
>+  select PMBUS
>+  select LM75
>+  select NEW_LEDS
>+  select LEDS_CLASS
>+  select LEDS_TRIGGERS
>+  select LEDS_TRIGGER_TIMER
>+  select LEDS_MLXCPLD
>+  ---help---
>+This option enables system support for the Mellanox Technologies
>+platform.
>+
>+Say Y here if you are building a kernel for Mellanox system.
>+
>+Otherwise, say N.
>+
> config AMD_NB
>   def_bool y
>   depends on CPU_SUP_AMD && PCI
>diff --git a/arch/x86/platform/Makefile b/arch/x86/platform/Makefile
>index 184842e..3c3c19e 100644
>--- a/arch/x86/platform/Makefile
>+++ b/arch/x86/platform/Makefile
>@@ -8,6 +8,7 @@ obj-y  += iris/
> obj-y += intel/
> obj-y += intel-mid/
> obj-y += intel-quark/
>+obj-y += mellanox/
> obj-y += olpc/
> obj-y += scx200/
> obj-y += sfi/
>diff --git a/arch/x86/platform/mellanox/Makefile
>b/arch/x86/platform/mellanox/Makefile
>new file mode 100644
>index 000..f43c931
>--- /dev/null
>+++ b/arch/x86/platform/mellanox/Makefile
>@@ -0,0 +1 @@
>+obj-$(CONFIG_MLX_PLATFORM)+= mlx-platform.o
>diff --git a/arch/x86/platform/mellanox/mlx-platform.c
>b/arch/x86/platform/mellanox/mlx-platform.c
>new file mode 100644
>index 000..02afa89
>--- /dev/null
>+++ b/arch/x86/platform/mellanox/mlx-platform.c
>@@ -0,0 +1,501 @@
>+/*
>+ * arch/x86/platform/mellanox/mlx-platform.c
>+ * Copyright (c) 2016 Mellanox Technologies. All rights reserved.
>+ * Copyright (c) 2016 Vadim Pasternak 
>+ *
>+ * Redistribution and use in source and binary forms, with or without
>+ * modification, are permitted provided that the following conditions
>are met:
>+ *
>+ * 1. Redistributions of source code must retain the above copyright
>+ *notice, this list of conditions and the following disclaimer.
>+ * 2. Redistributions in binary form must reproduce the above
>copyright
>+ *notice, this list of conditions and the following disclaimer in
>the
>+ *documentation and/or other materials provided with the
>distribution.
>+ * 3. Neither the names of the copyright holders nor the names of its
>+ *contributors may be used to endorse or promote products derived
>from
>+ *this software without specific prior written permission.
>+ *
>+ * Alternatively, this software may be distributed under the terms of
>the
>+ * GNU General Public License ("GPL") version 2 as published by the
>Free
>+ * Software Foundation.
>+ *
>+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>"AS IS"
>+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
>TO, THE
>+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
>PURPOSE
>+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
>CONTRIBUTORS BE
>+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
>+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 

Re: [patch v1] x86/platform/mellanox: introduce support for Mellanox systems platform

[H. Peter Anvin]

On September 11, 2016 11:29:58 PM PDT, vad...@mellanox.com wrote:
>From: Vadim Pasternak 
>
>Enable system support for the Mellanox Technologies platform, which
>provides support for the next Mellanox basic systems: "msx6710",
>"msx6720", "msb7700", "msn2700", "msx1410", "msn2410", "msb7800",
>"msn2740", "msn2100" and also various number of derivative systems from
>the above basic types.
>
>The Kconfig currently controlling compilation of this code is:
>arch/x86/platform:config MLX_PLATFORM
>arch/x86/platform:  tristate "Mellanox Technologies platform
>support"
>
>Signed-off-by: Vadim Pasternak 
>---
> MAINTAINERS   |   7 +
> arch/x86/Kconfig  |  23 ++
> arch/x86/platform/Makefile|   1 +
> arch/x86/platform/mellanox/Makefile   |   1 +
>arch/x86/platform/mellanox/mlx-platform.c | 501
>++
> 5 files changed, 533 insertions(+)
> create mode 100644 arch/x86/platform/mellanox/Makefile
> create mode 100644 arch/x86/platform/mellanox/mlx-platform.c
>
>diff --git a/MAINTAINERS b/MAINTAINERS
>index 4705c94..8a675de 100644
>--- a/MAINTAINERS
>+++ b/MAINTAINERS
>@@ -7664,6 +7664,13 @@ W:  http://www.mellanox.com
> Q:http://patchwork.ozlabs.org/project/netdev/list/
> F:drivers/net/ethernet/mellanox/mlxsw/
> 
>+MELLANOX PLATFORM DRIVER
>+M:  Vadim Pasternak 
>+L:  platform-driver-...@vger.kernel.org
>+S:  Supported
>+W:  http://www.mellanox.com
>+F:  arch/x86/platform/mellanox/mlx-platform.c
>+
> SOFT-ROCE DRIVER (rxe)
> M:Moni Shoua 
> L:linux-r...@vger.kernel.org
>diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
>index c580d8c..cc7efdd9 100644
>--- a/arch/x86/Kconfig
>+++ b/arch/x86/Kconfig
>@@ -2631,6 +2631,29 @@ config TS5500
> 
> endif # X86_32
> 
>+config MLX_PLATFORM
>+  tristate "Mellanox Technologies platform support"
>+  depends on X86_64
>+  depends on PCI
>+  depends on DMI
>+  depends on I2C_MLXCPLD
>+  depends on I2C_MUX_REG
>+  select HWMON
>+  select PMBUS
>+  select LM75
>+  select NEW_LEDS
>+  select LEDS_CLASS
>+  select LEDS_TRIGGERS
>+  select LEDS_TRIGGER_TIMER
>+  select LEDS_MLXCPLD
>+  ---help---
>+This option enables system support for the Mellanox Technologies
>+platform.
>+
>+Say Y here if you are building a kernel for Mellanox system.
>+
>+Otherwise, say N.
>+
> config AMD_NB
>   def_bool y
>   depends on CPU_SUP_AMD && PCI
>diff --git a/arch/x86/platform/Makefile b/arch/x86/platform/Makefile
>index 184842e..3c3c19e 100644
>--- a/arch/x86/platform/Makefile
>+++ b/arch/x86/platform/Makefile
>@@ -8,6 +8,7 @@ obj-y  += iris/
> obj-y += intel/
> obj-y += intel-mid/
> obj-y += intel-quark/
>+obj-y += mellanox/
> obj-y += olpc/
> obj-y += scx200/
> obj-y += sfi/
>diff --git a/arch/x86/platform/mellanox/Makefile
>b/arch/x86/platform/mellanox/Makefile
>new file mode 100644
>index 000..f43c931
>--- /dev/null
>+++ b/arch/x86/platform/mellanox/Makefile
>@@ -0,0 +1 @@
>+obj-$(CONFIG_MLX_PLATFORM)+= mlx-platform.o
>diff --git a/arch/x86/platform/mellanox/mlx-platform.c
>b/arch/x86/platform/mellanox/mlx-platform.c
>new file mode 100644
>index 000..02afa89
>--- /dev/null
>+++ b/arch/x86/platform/mellanox/mlx-platform.c
>@@ -0,0 +1,501 @@
>+/*
>+ * arch/x86/platform/mellanox/mlx-platform.c
>+ * Copyright (c) 2016 Mellanox Technologies. All rights reserved.
>+ * Copyright (c) 2016 Vadim Pasternak 
>+ *
>+ * Redistribution and use in source and binary forms, with or without
>+ * modification, are permitted provided that the following conditions
>are met:
>+ *
>+ * 1. Redistributions of source code must retain the above copyright
>+ *notice, this list of conditions and the following disclaimer.
>+ * 2. Redistributions in binary form must reproduce the above
>copyright
>+ *notice, this list of conditions and the following disclaimer in
>the
>+ *documentation and/or other materials provided with the
>distribution.
>+ * 3. Neither the names of the copyright holders nor the names of its
>+ *contributors may be used to endorse or promote products derived
>from
>+ *this software without specific prior written permission.
>+ *
>+ * Alternatively, this software may be distributed under the terms of
>the
>+ * GNU General Public License ("GPL") version 2 as published by the
>Free
>+ * Software Foundation.
>+ *
>+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
>"AS IS"
>+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
>TO, THE
>+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
>PURPOSE
>+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
>CONTRIBUTORS BE
>+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
>+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
>OF
>+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
>BUSINESS

[patch v1] x86/platform/mellanox: introduce support for Mellanox systems platform

[vadimp]

From: Vadim Pasternak 

Enable system support for the Mellanox Technologies platform, which
provides support for the next Mellanox basic systems: "msx6710",
"msx6720", "msb7700", "msn2700", "msx1410", "msn2410", "msb7800",
"msn2740", "msn2100" and also various number of derivative systems from
the above basic types.

The Kconfig currently controlling compilation of this code is:
arch/x86/platform:config MLX_PLATFORM
arch/x86/platform:  tristate "Mellanox Technologies platform support"

Signed-off-by: Vadim Pasternak 
---
 MAINTAINERS   |   7 +
 arch/x86/Kconfig  |  23 ++
 arch/x86/platform/Makefile|   1 +
 arch/x86/platform/mellanox/Makefile   |   1 +
 arch/x86/platform/mellanox/mlx-platform.c | 501 ++
 5 files changed, 533 insertions(+)
 create mode 100644 arch/x86/platform/mellanox/Makefile
 create mode 100644 arch/x86/platform/mellanox/mlx-platform.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 4705c94..8a675de 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7664,6 +7664,13 @@ W:   http://www.mellanox.com
 Q: http://patchwork.ozlabs.org/project/netdev/list/
 F: drivers/net/ethernet/mellanox/mlxsw/
 
+MELLANOX PLATFORM DRIVER
+M:  Vadim Pasternak 
+L:  platform-driver-...@vger.kernel.org
+S:  Supported
+W:  http://www.mellanox.com
+F:  arch/x86/platform/mellanox/mlx-platform.c
+
 SOFT-ROCE DRIVER (rxe)
 M: Moni Shoua 
 L: linux-r...@vger.kernel.org
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index c580d8c..cc7efdd9 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2631,6 +2631,29 @@ config TS5500
 
 endif # X86_32
 
+config MLX_PLATFORM
+   tristate "Mellanox Technologies platform support"
+   depends on X86_64
+   depends on PCI
+   depends on DMI
+   depends on I2C_MLXCPLD
+   depends on I2C_MUX_REG
+   select HWMON
+   select PMBUS
+   select LM75
+   select NEW_LEDS
+   select LEDS_CLASS
+   select LEDS_TRIGGERS
+   select LEDS_TRIGGER_TIMER
+   select LEDS_MLXCPLD
+   ---help---
+ This option enables system support for the Mellanox Technologies
+ platform.
+
+ Say Y here if you are building a kernel for Mellanox system.
+
+ Otherwise, say N.
+
 config AMD_NB
def_bool y
depends on CPU_SUP_AMD && PCI
diff --git a/arch/x86/platform/Makefile b/arch/x86/platform/Makefile
index 184842e..3c3c19e 100644
--- a/arch/x86/platform/Makefile
+++ b/arch/x86/platform/Makefile
@@ -8,6 +8,7 @@ obj-y   += iris/
 obj-y  += intel/
 obj-y  += intel-mid/
 obj-y  += intel-quark/
+obj-y  += mellanox/
 obj-y  += olpc/
 obj-y  += scx200/
 obj-y  += sfi/
diff --git a/arch/x86/platform/mellanox/Makefile 
b/arch/x86/platform/mellanox/Makefile
new file mode 100644
index 000..f43c931
--- /dev/null
+++ b/arch/x86/platform/mellanox/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_MLX_PLATFORM) += mlx-platform.o
diff --git a/arch/x86/platform/mellanox/mlx-platform.c 
b/arch/x86/platform/mellanox/mlx-platform.c
new file mode 100644
index 000..02afa89
--- /dev/null
+++ b/arch/x86/platform/mellanox/mlx-platform.c
@@ -0,0 +1,501 @@
+/*
+ * arch/x86/platform/mellanox/mlx-platform.c
+ * Copyright (c) 2016 Mellanox Technologies. All rights reserved.
+ * Copyright (c) 2016 Vadim Pasternak 
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. Neither the names of the copyright holders nor the names of its
+ *contributors may be used to endorse or promote products derived from
+ *this software without specific prior written permission.
+ *
+ * Alternatively, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") version 2 as published by the Free
+ * Software Foundation.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, 

[patch v1] x86/platform/mellanox: introduce support for Mellanox systems platform

[vadimp]

From: Vadim Pasternak 

Enable system support for the Mellanox Technologies platform, which
provides support for the next Mellanox basic systems: "msx6710",
"msx6720", "msb7700", "msn2700", "msx1410", "msn2410", "msb7800",
"msn2740", "msn2100" and also various number of derivative systems from
the above basic types.

The Kconfig currently controlling compilation of this code is:
arch/x86/platform:config MLX_PLATFORM
arch/x86/platform:  tristate "Mellanox Technologies platform support"

Signed-off-by: Vadim Pasternak 
---
 MAINTAINERS   |   7 +
 arch/x86/Kconfig  |  23 ++
 arch/x86/platform/Makefile|   1 +
 arch/x86/platform/mellanox/Makefile   |   1 +
 arch/x86/platform/mellanox/mlx-platform.c | 501 ++
 5 files changed, 533 insertions(+)
 create mode 100644 arch/x86/platform/mellanox/Makefile
 create mode 100644 arch/x86/platform/mellanox/mlx-platform.c

diff --git a/MAINTAINERS b/MAINTAINERS
index 4705c94..8a675de 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7664,6 +7664,13 @@ W:   http://www.mellanox.com
 Q: http://patchwork.ozlabs.org/project/netdev/list/
 F: drivers/net/ethernet/mellanox/mlxsw/
 
+MELLANOX PLATFORM DRIVER
+M:  Vadim Pasternak 
+L:  platform-driver-...@vger.kernel.org
+S:  Supported
+W:  http://www.mellanox.com
+F:  arch/x86/platform/mellanox/mlx-platform.c
+
 SOFT-ROCE DRIVER (rxe)
 M: Moni Shoua 
 L: linux-r...@vger.kernel.org
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index c580d8c..cc7efdd9 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2631,6 +2631,29 @@ config TS5500
 
 endif # X86_32
 
+config MLX_PLATFORM
+   tristate "Mellanox Technologies platform support"
+   depends on X86_64
+   depends on PCI
+   depends on DMI
+   depends on I2C_MLXCPLD
+   depends on I2C_MUX_REG
+   select HWMON
+   select PMBUS
+   select LM75
+   select NEW_LEDS
+   select LEDS_CLASS
+   select LEDS_TRIGGERS
+   select LEDS_TRIGGER_TIMER
+   select LEDS_MLXCPLD
+   ---help---
+ This option enables system support for the Mellanox Technologies
+ platform.
+
+ Say Y here if you are building a kernel for Mellanox system.
+
+ Otherwise, say N.
+
 config AMD_NB
def_bool y
depends on CPU_SUP_AMD && PCI
diff --git a/arch/x86/platform/Makefile b/arch/x86/platform/Makefile
index 184842e..3c3c19e 100644
--- a/arch/x86/platform/Makefile
+++ b/arch/x86/platform/Makefile
@@ -8,6 +8,7 @@ obj-y   += iris/
 obj-y  += intel/
 obj-y  += intel-mid/
 obj-y  += intel-quark/
+obj-y  += mellanox/
 obj-y  += olpc/
 obj-y  += scx200/
 obj-y  += sfi/
diff --git a/arch/x86/platform/mellanox/Makefile 
b/arch/x86/platform/mellanox/Makefile
new file mode 100644
index 000..f43c931
--- /dev/null
+++ b/arch/x86/platform/mellanox/Makefile
@@ -0,0 +1 @@
+obj-$(CONFIG_MLX_PLATFORM) += mlx-platform.o
diff --git a/arch/x86/platform/mellanox/mlx-platform.c 
b/arch/x86/platform/mellanox/mlx-platform.c
new file mode 100644
index 000..02afa89
--- /dev/null
+++ b/arch/x86/platform/mellanox/mlx-platform.c
@@ -0,0 +1,501 @@
+/*
+ * arch/x86/platform/mellanox/mlx-platform.c
+ * Copyright (c) 2016 Mellanox Technologies. All rights reserved.
+ * Copyright (c) 2016 Vadim Pasternak 
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, this list of conditions and the following disclaimer.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. Neither the names of the copyright holders nor the names of its
+ *contributors may be used to endorse or promote products derived from
+ *this software without specific prior written permission.
+ *
+ * Alternatively, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") version 2 as published by the Free
+ * Software Foundation.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
+ * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
+ * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY 

Re: [PATCH v2 06/33] Documentation, x86: Documentation for Intel resource allocation user interface

[Shaohua Li]

On Sat, Sep 10, 2016 at 12:36:57AM +, Yu, Fenghua wrote:
> > > Hmm, I don't know how applications are going to use the interface.
> > > Nobody knows it right now. But we do have some candicate workloads
> > > which want to configure the cache partition at runtime, so it's not
> > > just a boot time stuff. I'm wondering why we have such limitation. The
> > > framework is there, it's quite easy to implement process move in
> > > kernel but fairly hard to get it right in userspace.
> > 
> > You are correct - if there is a need for this, it would be better done in 
> > the
> > kernel.
> > 
> > I'm just not sure how to explain both a "procs" and "tasks" interface file 
> > in a
> > way that won't confuse people.
> > 
> > We have:
> > 
> > # echo {task-id} > tasks
> >    adds a single task to this resource group # cat tasks
> >   ... shows all the tasks in this resource group
> > 
> > and you want:
> > 
> > # echo {process-id} > procs
> >... adds all threads in {process-id} to this resource group # cat procs
> >   ... shows all processes (like "cat tasks" above, but only shows main 
> > thread in
> > a multi-threads process)
> 
> The advantage of "tasks" is user can allocate each thread into its own 
> partition.
> The advantage of "procs" is convenience for user to just allocate thread group
> lead pid and rest of the thread group members go with the lead.
> 
> If no "procs" is really inconvenience, we may support "procs" in future.
> 
> One way to implement this is we can extend the current interface to accept
> a resctrl file system mount parameter to switch b/w "procs" and "tasks" during
> mount time. So the file sytem has either "procs" or "tasks" during run time. 
> I don't think it's right to have both of them at the same time in the file 
> system.

A mount option doesn't make sense, which just creates more trouble. What's
wrong to have both of 'procs' and 'tasks' at the same time, like cgroup? I
think it's more natural to support both. As for the content of 'procs' and
'tasks', we could follow how cgroup handle them.

Thanks,
Shaohua

Re: [PATCH v2 06/33] Documentation, x86: Documentation for Intel resource allocation user interface

[Shaohua Li]

On Sat, Sep 10, 2016 at 12:36:57AM +, Yu, Fenghua wrote:
> > > Hmm, I don't know how applications are going to use the interface.
> > > Nobody knows it right now. But we do have some candicate workloads
> > > which want to configure the cache partition at runtime, so it's not
> > > just a boot time stuff. I'm wondering why we have such limitation. The
> > > framework is there, it's quite easy to implement process move in
> > > kernel but fairly hard to get it right in userspace.
> > 
> > You are correct - if there is a need for this, it would be better done in 
> > the
> > kernel.
> > 
> > I'm just not sure how to explain both a "procs" and "tasks" interface file 
> > in a
> > way that won't confuse people.
> > 
> > We have:
> > 
> > # echo {task-id} > tasks
> >    adds a single task to this resource group # cat tasks
> >   ... shows all the tasks in this resource group
> > 
> > and you want:
> > 
> > # echo {process-id} > procs
> >... adds all threads in {process-id} to this resource group # cat procs
> >   ... shows all processes (like "cat tasks" above, but only shows main 
> > thread in
> > a multi-threads process)
> 
> The advantage of "tasks" is user can allocate each thread into its own 
> partition.
> The advantage of "procs" is convenience for user to just allocate thread group
> lead pid and rest of the thread group members go with the lead.
> 
> If no "procs" is really inconvenience, we may support "procs" in future.
> 
> One way to implement this is we can extend the current interface to accept
> a resctrl file system mount parameter to switch b/w "procs" and "tasks" during
> mount time. So the file sytem has either "procs" or "tasks" during run time. 
> I don't think it's right to have both of them at the same time in the file 
> system.

A mount option doesn't make sense, which just creates more trouble. What's
wrong to have both of 'procs' and 'tasks' at the same time, like cgroup? I
think it's more natural to support both. As for the content of 'procs' and
'tasks', we could follow how cgroup handle them.

Thanks,
Shaohua

[PATCH v2] cpuset: handle race between CPU hotplug and cpuset_hotplug_work

[Joonwoo Park]

A discrepancy between cpu_online_mask and cpuset's effective_cpus
mask is inevitable during hotplug since cpuset defers updating of
effective_cpus mask using a workqueue, during which time nothing
prevents the system from more hotplug operations.  For that reason
guarantee_online_cpus() walks up the cpuset hierarchy until it finds
an intersection under the assumption that top cpuset's effective_cpus
mask intersects with cpu_online_mask even with such a race occurring.

However a sequence of CPU hotplugs can open a time window, during which
none of the effective CPUs in the top cpuset intersect with
cpu_online_mask.

For example when there are 4 possible CPUs 0-3 and only CPU0 is online:

    ===
   cpu_online_mask   top_cpuset.effective_cpus
    ===
   echo 1 > cpu2/online.
   CPU hotplug notifier woke up hotplug work but not yet scheduled.
  [0,2] [0]

   echo 0 > cpu0/online.
   The workqueue is still runnable.
  [2]   [0]
    ===

  Now there is no intersection between cpu_online_mask and
  top_cpuset.effective_cpus.  Thus invoking sys_sched_setaffinity() at
  this moment can cause following:

   Unable to handle kernel NULL pointer dereference at virtual address 00d0
   [ cut here ]
   Kernel BUG at ffc0001389b0 [verbose debug info unavailable]
   Internal error: Oops - BUG: 9605 [#1] PREEMPT SMP
   Modules linked in:
   CPU: 2 PID: 1420 Comm: taskset Tainted: GW   4.4.8+ #98
   task: ffc06a5c4880 ti: ffc06e124000 task.ti: ffc06e124000
   PC is at guarantee_online_cpus+0x2c/0x58
   LR is at cpuset_cpus_allowed+0x4c/0x6c
   
   Process taskset (pid: 1420, stack limit = 0xffc06e124020)
   Call trace:
   [] guarantee_online_cpus+0x2c/0x58
   [] cpuset_cpus_allowed+0x4c/0x6c
   [] sched_setaffinity+0xc0/0x1ac
   [] SyS_sched_setaffinity+0x98/0xac
   [] el0_svc_naked+0x24/0x28

The top cpuset's effective_cpus are guaranteed to be identical to
cpu_online_mask eventually.  Hence fall back to cpu_online_mask when
there is no intersection between top cpuset's effective_cpus and
cpu_online_mask.

Signed-off-by: Joonwoo Park 
Cc: Li Zefan 
Cc: Tejun Heo 
Cc: cgro...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc:  # 3.17+
---
 v2: fixed changelog and comment.

 kernel/cpuset.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index 73e93e5..27c6d78 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -325,8 +325,7 @@ static struct file_system_type cpuset_fs_type = {
 /*
  * Return in pmask the portion of a cpusets's cpus_allowed that
  * are online.  If none are online, walk up the cpuset hierarchy
- * until we find one that does have some online cpus.  The top
- * cpuset always has some cpus online.
+ * until we find one that does have some online cpus.
  *
  * One way or another, we guarantee to return some non-empty subset
  * of cpu_online_mask.
@@ -335,8 +334,20 @@ static struct file_system_type cpuset_fs_type = {
  */
 static void guarantee_online_cpus(struct cpuset *cs, struct cpumask *pmask)
 {
-   while (!cpumask_intersects(cs->effective_cpus, cpu_online_mask))
+   while (!cpumask_intersects(cs->effective_cpus, cpu_online_mask)) {
cs = parent_cs(cs);
+   if (unlikely(!cs)) {
+   /*
+* The top cpuset doesn't have any online cpu as a
+* consequence of a race between cpuset_hotplug_work
+* and cpu hotplug notifier.  But we know the top
+* cpuset's effective_cpus is on its way to to be
+* identical to cpu_online_mask.
+*/
+   cpumask_copy(pmask, cpu_online_mask);
+   return;
+   }
+   }
cpumask_and(pmask, cs->effective_cpus, cpu_online_mask);
 }
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

[PATCH v2] cpuset: handle race between CPU hotplug and cpuset_hotplug_work

[Joonwoo Park]

A discrepancy between cpu_online_mask and cpuset's effective_cpus
mask is inevitable during hotplug since cpuset defers updating of
effective_cpus mask using a workqueue, during which time nothing
prevents the system from more hotplug operations.  For that reason
guarantee_online_cpus() walks up the cpuset hierarchy until it finds
an intersection under the assumption that top cpuset's effective_cpus
mask intersects with cpu_online_mask even with such a race occurring.

However a sequence of CPU hotplugs can open a time window, during which
none of the effective CPUs in the top cpuset intersect with
cpu_online_mask.

For example when there are 4 possible CPUs 0-3 and only CPU0 is online:

    ===
   cpu_online_mask   top_cpuset.effective_cpus
    ===
   echo 1 > cpu2/online.
   CPU hotplug notifier woke up hotplug work but not yet scheduled.
  [0,2] [0]

   echo 0 > cpu0/online.
   The workqueue is still runnable.
  [2]   [0]
    ===

  Now there is no intersection between cpu_online_mask and
  top_cpuset.effective_cpus.  Thus invoking sys_sched_setaffinity() at
  this moment can cause following:

   Unable to handle kernel NULL pointer dereference at virtual address 00d0
   [ cut here ]
   Kernel BUG at ffc0001389b0 [verbose debug info unavailable]
   Internal error: Oops - BUG: 9605 [#1] PREEMPT SMP
   Modules linked in:
   CPU: 2 PID: 1420 Comm: taskset Tainted: GW   4.4.8+ #98
   task: ffc06a5c4880 ti: ffc06e124000 task.ti: ffc06e124000
   PC is at guarantee_online_cpus+0x2c/0x58
   LR is at cpuset_cpus_allowed+0x4c/0x6c
   
   Process taskset (pid: 1420, stack limit = 0xffc06e124020)
   Call trace:
   [] guarantee_online_cpus+0x2c/0x58
   [] cpuset_cpus_allowed+0x4c/0x6c
   [] sched_setaffinity+0xc0/0x1ac
   [] SyS_sched_setaffinity+0x98/0xac
   [] el0_svc_naked+0x24/0x28

The top cpuset's effective_cpus are guaranteed to be identical to
cpu_online_mask eventually.  Hence fall back to cpu_online_mask when
there is no intersection between top cpuset's effective_cpus and
cpu_online_mask.

Signed-off-by: Joonwoo Park 
Cc: Li Zefan 
Cc: Tejun Heo 
Cc: cgro...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc:  # 3.17+
---
 v2: fixed changelog and comment.

 kernel/cpuset.c | 17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

diff --git a/kernel/cpuset.c b/kernel/cpuset.c
index 73e93e5..27c6d78 100644
--- a/kernel/cpuset.c
+++ b/kernel/cpuset.c
@@ -325,8 +325,7 @@ static struct file_system_type cpuset_fs_type = {
 /*
  * Return in pmask the portion of a cpusets's cpus_allowed that
  * are online.  If none are online, walk up the cpuset hierarchy
- * until we find one that does have some online cpus.  The top
- * cpuset always has some cpus online.
+ * until we find one that does have some online cpus.
  *
  * One way or another, we guarantee to return some non-empty subset
  * of cpu_online_mask.
@@ -335,8 +334,20 @@ static struct file_system_type cpuset_fs_type = {
  */
 static void guarantee_online_cpus(struct cpuset *cs, struct cpumask *pmask)
 {
-   while (!cpumask_intersects(cs->effective_cpus, cpu_online_mask))
+   while (!cpumask_intersects(cs->effective_cpus, cpu_online_mask)) {
cs = parent_cs(cs);
+   if (unlikely(!cs)) {
+   /*
+* The top cpuset doesn't have any online cpu as a
+* consequence of a race between cpuset_hotplug_work
+* and cpu hotplug notifier.  But we know the top
+* cpuset's effective_cpus is on its way to to be
+* identical to cpu_online_mask.
+*/
+   cpumask_copy(pmask, cpu_online_mask);
+   return;
+   }
+   }
cpumask_and(pmask, cs->effective_cpus, cpu_online_mask);
 }
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

Re: [PATCH] tpm: fix buffer overflow in /dev/tpm0

[Jason Gunthorpe]

On Sun, Sep 11, 2016 at 03:19:00PM +0300, Jarkko Sakkinen wrote:
> tpm_write() does not check whether the buffer has at least enough space
> for the header before passing it to tpm_transmit() so an overflow can
> happen.

Eh?

tpm_write uses a hard wired buffer size of TPM_BUFSIZE when working
with tpm_transmit.

in_size is never used except for the copy. We should probably fix that
to sanity check the header length vs in_size.

That doesn't seem to be a security issue however because the header
length is propery limited to TPM_BUFSIZE and the data buffer is
allocated specifically for that process using kzalloc.

Jason

Re: [PATCH] cpuset: handle race between CPU hotplug and cpuset_hotplug_work

[Joonwoo Park]

On Mon, Sep 12, 2016 at 10:48:31AM +0800, Zefan Li wrote:
> Cc: Tejun
> 
> On 2016/9/9 8:41, Joonwoo Park wrote:
> > Discrepancy between cpu_online_mask and cpuset's effective CPU masks on
> > cpuset hierarchy is inevitable since cpuset defers updating of
> > effective CPU masks with workqueue while nothing prevents system from
> > doing CPU hotplug.  For that reason guarantee_online_cpus() walks up
> > the cpuset hierarchy until it finds intersection under the assumption
> > that top cpuset's effective CPU mask intersects with cpu_online_mask
> > even under such race.
> > 
> > However a sequence of CPU hotplugs can open a time window which is none
> > of effective CPUs in the top cpuset intersects with cpu_online_mask.
> > 
> > For example when there are 4 possible CPUs 0-3 where only CPU0 is online:
> > 
> >     ===
> >cpu_online_mask   top_cpuset.effective_cpus
> >     ===
> >echo 1 > cpu2/online.
> >CPU hotplug notifier woke up hotplug work but not yet scheduled.
> >   [0,2] [0]
> > 
> >echo 0 > cpu0/online.
> >The workqueue is still runnable.
> >   [2]   [0]
> >     ===
> > 
> >   Now there is no intersection between cpu_online_mask and
> >   top_cpuset.effective_cpus.  Thus invoking sys_sched_setaffinity() at
> >   this moment can cause following:
> > 
> >Unable to handle kernel NULL pointer dereference at virtual address 
> > 00d0
> >[ cut here ]
> >Kernel BUG at ffc0001389b0 [verbose debug info unavailable]
> >Internal error: Oops - BUG: 9605 [#1] PREEMPT SMP
> >Modules linked in:
> >CPU: 2 PID: 1420 Comm: taskset Tainted: GW   4.4.8+ #98
> >task: ffc06a5c4880 ti: ffc06e124000 task.ti: ffc06e124000
> >PC is at guarantee_online_cpus+0x2c/0x58
> >LR is at cpuset_cpus_allowed+0x4c/0x6c
> >
> >Process taskset (pid: 1420, stack limit = 0xffc06e124020)
> >Call trace:
> >[] guarantee_online_cpus+0x2c/0x58
> >[] cpuset_cpus_allowed+0x4c/0x6c
> >[] sched_setaffinity+0xc0/0x1ac
> >[] SyS_sched_setaffinity+0x98/0xac
> >[] el0_svc_naked+0x24/0x28
> > 
> > The top cpuset's effective_cpus are guaranteed to be identical to online
> > CPUs eventually.  Hence fall back to online CPU mask when there is no
> > intersection between top cpuset's effective_cpus and online CPU mask.
> > 
> > Signed-off-by: Joonwoo Park 
> > Cc: Li Zefan 
> > Cc: cgro...@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> 
> Thanks for fixing this!
> 
> Acked-by: Zefan Li 
> Cc:  # 3.17+
> 

Thanks for reviewing.

Shortly I will send v2 which has few grammar error fixes in the
changelog.
No code change has made.

Joonwoo

Re: [PATCH] tpm: fix buffer overflow in /dev/tpm0

[Jason Gunthorpe]

On Sun, Sep 11, 2016 at 03:19:00PM +0300, Jarkko Sakkinen wrote:
> tpm_write() does not check whether the buffer has at least enough space
> for the header before passing it to tpm_transmit() so an overflow can
> happen.

Eh?

tpm_write uses a hard wired buffer size of TPM_BUFSIZE when working
with tpm_transmit.

in_size is never used except for the copy. We should probably fix that
to sanity check the header length vs in_size.

That doesn't seem to be a security issue however because the header
length is propery limited to TPM_BUFSIZE and the data buffer is
allocated specifically for that process using kzalloc.

Jason

Re: [PATCH] cpuset: handle race between CPU hotplug and cpuset_hotplug_work

[Joonwoo Park]

On Mon, Sep 12, 2016 at 10:48:31AM +0800, Zefan Li wrote:
> Cc: Tejun
> 
> On 2016/9/9 8:41, Joonwoo Park wrote:
> > Discrepancy between cpu_online_mask and cpuset's effective CPU masks on
> > cpuset hierarchy is inevitable since cpuset defers updating of
> > effective CPU masks with workqueue while nothing prevents system from
> > doing CPU hotplug.  For that reason guarantee_online_cpus() walks up
> > the cpuset hierarchy until it finds intersection under the assumption
> > that top cpuset's effective CPU mask intersects with cpu_online_mask
> > even under such race.
> > 
> > However a sequence of CPU hotplugs can open a time window which is none
> > of effective CPUs in the top cpuset intersects with cpu_online_mask.
> > 
> > For example when there are 4 possible CPUs 0-3 where only CPU0 is online:
> > 
> >     ===
> >cpu_online_mask   top_cpuset.effective_cpus
> >     ===
> >echo 1 > cpu2/online.
> >CPU hotplug notifier woke up hotplug work but not yet scheduled.
> >   [0,2] [0]
> > 
> >echo 0 > cpu0/online.
> >The workqueue is still runnable.
> >   [2]   [0]
> >     ===
> > 
> >   Now there is no intersection between cpu_online_mask and
> >   top_cpuset.effective_cpus.  Thus invoking sys_sched_setaffinity() at
> >   this moment can cause following:
> > 
> >Unable to handle kernel NULL pointer dereference at virtual address 
> > 00d0
> >[ cut here ]
> >Kernel BUG at ffc0001389b0 [verbose debug info unavailable]
> >Internal error: Oops - BUG: 9605 [#1] PREEMPT SMP
> >Modules linked in:
> >CPU: 2 PID: 1420 Comm: taskset Tainted: GW   4.4.8+ #98
> >task: ffc06a5c4880 ti: ffc06e124000 task.ti: ffc06e124000
> >PC is at guarantee_online_cpus+0x2c/0x58
> >LR is at cpuset_cpus_allowed+0x4c/0x6c
> >
> >Process taskset (pid: 1420, stack limit = 0xffc06e124020)
> >Call trace:
> >[] guarantee_online_cpus+0x2c/0x58
> >[] cpuset_cpus_allowed+0x4c/0x6c
> >[] sched_setaffinity+0xc0/0x1ac
> >[] SyS_sched_setaffinity+0x98/0xac
> >[] el0_svc_naked+0x24/0x28
> > 
> > The top cpuset's effective_cpus are guaranteed to be identical to online
> > CPUs eventually.  Hence fall back to online CPU mask when there is no
> > intersection between top cpuset's effective_cpus and online CPU mask.
> > 
> > Signed-off-by: Joonwoo Park 
> > Cc: Li Zefan 
> > Cc: cgro...@vger.kernel.org
> > Cc: linux-kernel@vger.kernel.org
> 
> Thanks for fixing this!
> 
> Acked-by: Zefan Li 
> Cc:  # 3.17+
> 

Thanks for reviewing.

Shortly I will send v2 which has few grammar error fixes in the
changelog.
No code change has made.

Joonwoo

mipsel-linux-gnu-gcc: error: unrecognized command line option '-mcompact-branches=optimal'

[kbuild test robot]

Hi Paul,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   9395452b4aab7bc2475ef8935b4a4fb99d778d70
commit: c1a0e9bc885d46e519fd87d35af6a7937abfb986 MIPS: Allow compact branch 
policy to be changed
date:   11 months ago
config: mips-malta_qemu_32r6_defconfig (attached as .config)
compiler: mipsel-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout c1a0e9bc885d46e519fd87d35af6a7937abfb986
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> mipsel-linux-gnu-gcc: error: unrecognized command line option 
>> '-mcompact-branches=optimal'
>> mipsel-linux-gnu-gcc: error: unrecognized command line option 
>> '-mcompact-branches=optimal'
   make[2]: *** [kernel/bounds.s] Error 1
   make[2]: Target '__build' not remade because of errors.
   make[1]: *** [prepare0] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [sub-make] Error 2

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

mipsel-linux-gnu-gcc: error: unrecognized command line option '-mcompact-branches=optimal'

[kbuild test robot]

Hi Paul,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   9395452b4aab7bc2475ef8935b4a4fb99d778d70
commit: c1a0e9bc885d46e519fd87d35af6a7937abfb986 MIPS: Allow compact branch 
policy to be changed
date:   11 months ago
config: mips-malta_qemu_32r6_defconfig (attached as .config)
compiler: mipsel-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout c1a0e9bc885d46e519fd87d35af6a7937abfb986
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> mipsel-linux-gnu-gcc: error: unrecognized command line option 
>> '-mcompact-branches=optimal'
>> mipsel-linux-gnu-gcc: error: unrecognized command line option 
>> '-mcompact-branches=optimal'
   make[2]: *** [kernel/bounds.s] Error 1
   make[2]: Target '__build' not remade because of errors.
   make[1]: *** [prepare0] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [sub-make] Error 2

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)

[Rudoff, Andy]

>Whether msync/fsync can make data persistent depends on ADR feature on
>memory controller, if it exists everything works well, otherwise, we need
>to have another interface that is why 'Flush hint table' in ACPI comes
>in. 'Flush hint table' is particularly useful for nvdimm virtualization if
>we use normal memory to emulate nvdimm with data persistent characteristic
>(the data will be flushed to a persistent storage, e.g, disk).
>
>Does current PMEM programming model fully supports 'Flush hint table'? Is
>userspace allowed to use these addresses?

The Flush hint table is NOT a replacement for ADR.  To support pmem on
the x86 architecture, the platform is required to ensure that a pmem
store flushed from the CPU caches is in the persistent domain so that the
application need not take any additional steps to make it persistent.
The most common way to do this is the ADR feature.

If the above is not true, then your x86 platform does not support pmem.

Flush hints are for use by the BIOS and drivers and are not intended to
be used in user space.  Flush hints provide two things:

First, if a driver needs to write to command registers or movable windows
on a DIMM, the Flush hint (if provided in the NFIT) is required to flush
the command to the DIMM or ensure stores done through the movable window
are complete before moving it somewhere else.

Second, for the rare case where the kernel wants to flush stores to the
smallest possible failure domain (i.e. to the DIMM even though ADR will
handle flushing it from a larger domain), the flush hints provide a way
to do this.  This might be useful for things like file system journals to
help ensure the file system is consistent even in the face of ADR failure.

-andy

Re: DAX mapping detection (was: Re: [PATCH] Fix region lost in /proc/self/smaps)

[Rudoff, Andy]

>Whether msync/fsync can make data persistent depends on ADR feature on
>memory controller, if it exists everything works well, otherwise, we need
>to have another interface that is why 'Flush hint table' in ACPI comes
>in. 'Flush hint table' is particularly useful for nvdimm virtualization if
>we use normal memory to emulate nvdimm with data persistent characteristic
>(the data will be flushed to a persistent storage, e.g, disk).
>
>Does current PMEM programming model fully supports 'Flush hint table'? Is
>userspace allowed to use these addresses?

The Flush hint table is NOT a replacement for ADR.  To support pmem on
the x86 architecture, the platform is required to ensure that a pmem
store flushed from the CPU caches is in the persistent domain so that the
application need not take any additional steps to make it persistent.
The most common way to do this is the ADR feature.

If the above is not true, then your x86 platform does not support pmem.

Flush hints are for use by the BIOS and drivers and are not intended to
be used in user space.  Flush hints provide two things:

First, if a driver needs to write to command registers or movable windows
on a DIMM, the Flush hint (if provided in the NFIT) is required to flush
the command to the DIMM or ensure stores done through the movable window
are complete before moving it somewhere else.

Second, for the rare case where the kernel wants to flush stores to the
smallest possible failure domain (i.e. to the DIMM even though ADR will
handle flushing it from a larger domain), the flush hints provide a way
to do this.  This might be useful for things like file system journals to
help ensure the file system is consistent even in the face of ADR failure.

-andy

Re: [RFC PATCH 1/2] mm, mincore2(): retrieve dax and tlb-size attributes of an address range

[Nicholas Piggin]

On Sun, 11 Sep 2016 10:31:35 -0700
Dan Williams  wrote:

> As evidenced by this bug report [1], userspace libraries are interested
> in whether a mapping is DAX mapped, i.e. no intervening page cache.
> Rather than using the ambiguous VM_MIXEDMAP flag in smaps, provide an
> explicit "is dax" indication as a new flag in the page vector populated
> by mincore.

Can you cc linux-arch when adding new syscalls (or other such things that
need arch enablement).

I wonder if the changelog for a new syscall should have a bit more grandeur.
Without seeing patch 2, you might not know this was a new syscall just by
reading the subject and changelog.

mincore() defines other bits to be reserved, but I guess it probably breaks
things if you suddenly started using them.

It's a bit sad to introduce a new syscall for this and immediately use up
all bits that can be returned. Would it be a serious problem to return a
larger mask per page?

Thanks,
Nick

Re: [RFC PATCH 1/2] mm, mincore2(): retrieve dax and tlb-size attributes of an address range

[Nicholas Piggin]

On Sun, 11 Sep 2016 10:31:35 -0700
Dan Williams  wrote:

> As evidenced by this bug report [1], userspace libraries are interested
> in whether a mapping is DAX mapped, i.e. no intervening page cache.
> Rather than using the ambiguous VM_MIXEDMAP flag in smaps, provide an
> explicit "is dax" indication as a new flag in the page vector populated
> by mincore.

Can you cc linux-arch when adding new syscalls (or other such things that
need arch enablement).

I wonder if the changelog for a new syscall should have a bit more grandeur.
Without seeing patch 2, you might not know this was a new syscall just by
reading the subject and changelog.

mincore() defines other bits to be reserved, but I guess it probably breaks
things if you suddenly started using them.

It's a bit sad to introduce a new syscall for this and immediately use up
all bits that can be returned. Would it be a serious problem to return a
larger mask per page?

Thanks,
Nick

[PATCH v2] mm, proc: Fix region lost in /proc/self/smaps

[Xiao Guangrong]

Recently, Redhat reported that nvml test suite failed on QEMU/KVM,
more detailed info please refer to:
   https://bugzilla.redhat.com/show_bug.cgi?id=1365721

Actually, this bug is not only for NVDIMM/DAX but also for any other file
systems. This simple test case abstracted from nvml can easily reproduce
this bug in common environment:

-- testcase.c -
#define PROCMAXLEN 4096

int
is_pmem_proc(const void *addr, size_t len)
{
const char *caddr = addr;

FILE *fp;
if ((fp = fopen("/proc/self/smaps", "r")) == NULL) {
printf("!/proc/self/smaps");
return 0;
}

int retval = 0; /* assume false until proven otherwise */
char line[PROCMAXLEN];  /* for fgets() */
char *lo = NULL;/* beginning of current range in smaps file */
char *hi = NULL;/* end of current range in smaps file */
int needmm = 0; /* looking for mm flag for current range */
while (fgets(line, PROCMAXLEN, fp) != NULL) {
static const char vmflags[] = "VmFlags:";
static const char mm[] = " wr";

/* check for range line */
if (sscanf(line, "%p-%p", , ) == 2) {
if (needmm) {
/* last range matched, but no mm flag found */
printf("never found mm flag.\n");
break;
} else if (caddr < lo) {
/* never found the range for caddr */
printf("###no match for addr %p.\n", caddr);
break;
} else if (caddr < hi) {
/* start address is in this range */
size_t rangelen = (size_t)(hi - caddr);

/* remember that matching has started */
needmm = 1;

/* calculate remaining range to search for */
if (len > rangelen) {
len -= rangelen;
caddr += rangelen;
printf("matched %zu bytes in range "
"%p-%p, %zu left over.\n",
rangelen, lo, hi, len);
} else {
len = 0;
printf("matched all bytes in range "
"%p-%p.\n", lo, hi);
}
}
} else if (needmm && strncmp(line, vmflags,
sizeof(vmflags) - 1) == 0) {
if (strstr([sizeof(vmflags) - 1], mm) != NULL) {
printf("mm flag found.\n");
if (len == 0) {
/* entire range matched */
retval = 1;
break;
}
needmm = 0; /* saw what was needed */
} else {
/* mm flag not set for some or all of range */
printf("range has no mm flag.\n");
break;
}
}
}

fclose(fp);

printf("returning %d.\n", retval);
return retval;
}

#define NTHREAD 16

void *Addr;
size_t Size;

/*
 * worker -- the work each thread performs
 */
static void *
worker(void *arg)
{
int *ret = (int *)arg;
*ret =  is_pmem_proc(Addr, Size);
return NULL;
}

int main(int argc, char *argv[])
{
if (argc <  2 || argc > 3) {
printf("usage: %s file [env].\n", argv[0]);
return -1;
}

int fd = open(argv[1], O_RDWR);

struct stat stbuf;
fstat(fd, );

Size = stbuf.st_size;
Addr = mmap(0, stbuf.st_size, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0);

close(fd);

pthread_t threads[NTHREAD];
int ret[NTHREAD];

/* kick off NTHREAD threads */
for (int i = 0; i < NTHREAD; i++)
pthread_create([i], NULL, worker, [i]);

/* wait for all the threads to complete */
for (int i = 0; i < NTHREAD; i++)
pthread_join(threads[i], NULL);

/* verify that all the threads return the same value */
for (int i = 1; i < NTHREAD; i++) {
if (ret[0] != ret[i]) {
printf("Error i %d ret[0] = %d ret[i] = %d.\n", i,
  

[PATCH v2] mm, proc: Fix region lost in /proc/self/smaps

[Xiao Guangrong]

Recently, Redhat reported that nvml test suite failed on QEMU/KVM,
more detailed info please refer to:
   https://bugzilla.redhat.com/show_bug.cgi?id=1365721

Actually, this bug is not only for NVDIMM/DAX but also for any other file
systems. This simple test case abstracted from nvml can easily reproduce
this bug in common environment:

-- testcase.c -
#define PROCMAXLEN 4096

int
is_pmem_proc(const void *addr, size_t len)
{
const char *caddr = addr;

FILE *fp;
if ((fp = fopen("/proc/self/smaps", "r")) == NULL) {
printf("!/proc/self/smaps");
return 0;
}

int retval = 0; /* assume false until proven otherwise */
char line[PROCMAXLEN];  /* for fgets() */
char *lo = NULL;/* beginning of current range in smaps file */
char *hi = NULL;/* end of current range in smaps file */
int needmm = 0; /* looking for mm flag for current range */
while (fgets(line, PROCMAXLEN, fp) != NULL) {
static const char vmflags[] = "VmFlags:";
static const char mm[] = " wr";

/* check for range line */
if (sscanf(line, "%p-%p", , ) == 2) {
if (needmm) {
/* last range matched, but no mm flag found */
printf("never found mm flag.\n");
break;
} else if (caddr < lo) {
/* never found the range for caddr */
printf("###no match for addr %p.\n", caddr);
break;
} else if (caddr < hi) {
/* start address is in this range */
size_t rangelen = (size_t)(hi - caddr);

/* remember that matching has started */
needmm = 1;

/* calculate remaining range to search for */
if (len > rangelen) {
len -= rangelen;
caddr += rangelen;
printf("matched %zu bytes in range "
"%p-%p, %zu left over.\n",
rangelen, lo, hi, len);
} else {
len = 0;
printf("matched all bytes in range "
"%p-%p.\n", lo, hi);
}
}
} else if (needmm && strncmp(line, vmflags,
sizeof(vmflags) - 1) == 0) {
if (strstr([sizeof(vmflags) - 1], mm) != NULL) {
printf("mm flag found.\n");
if (len == 0) {
/* entire range matched */
retval = 1;
break;
}
needmm = 0; /* saw what was needed */
} else {
/* mm flag not set for some or all of range */
printf("range has no mm flag.\n");
break;
}
}
}

fclose(fp);

printf("returning %d.\n", retval);
return retval;
}

#define NTHREAD 16

void *Addr;
size_t Size;

/*
 * worker -- the work each thread performs
 */
static void *
worker(void *arg)
{
int *ret = (int *)arg;
*ret =  is_pmem_proc(Addr, Size);
return NULL;
}

int main(int argc, char *argv[])
{
if (argc <  2 || argc > 3) {
printf("usage: %s file [env].\n", argv[0]);
return -1;
}

int fd = open(argv[1], O_RDWR);

struct stat stbuf;
fstat(fd, );

Size = stbuf.st_size;
Addr = mmap(0, stbuf.st_size, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0);

close(fd);

pthread_t threads[NTHREAD];
int ret[NTHREAD];

/* kick off NTHREAD threads */
for (int i = 0; i < NTHREAD; i++)
pthread_create([i], NULL, worker, [i]);

/* wait for all the threads to complete */
for (int i = 0; i < NTHREAD; i++)
pthread_join(threads[i], NULL);

/* verify that all the threads return the same value */
for (int i = 1; i < NTHREAD; i++) {
if (ret[0] != ret[i]) {
printf("Error i %d ret[0] = %d ret[i] = %d.\n", i,
  

Re: [PATCH] powerpc: set used_vsr/used_vr/used_spe in sigreturn path when MSR bits are active

[Simon Guo]

On Tue, Jul 26, 2016 at 04:06:01PM +0800, wei.guo.si...@gmail.com wrote:
> From: Simon Guo 
> 
> Normally, when MSR[VSX/VR/SPE] bits = 1, the used_vsr/used_vr/used_spe
> bit have already been set. However signal frame locates at user space
> and it is controlled by user application. It is up to kernel to make
> sure used_vsr/used_vr/used_spe(in kernel)=1 and consistent with MSR
> bits.
> 
> For example, CRIU application, who utilizes sigreturn to restore
> checkpointed process, will lead to the case where MSR[VSX] bit is
> active in signal frame, but used_vsx bit is not set. (the same applies
> to VR/SPE).
> 
> This patch will reinforce this at kernel by always setting used_* bit
> when MSR related bits are active in signal frame and we are doing
> sigreturn.
> 
> This patch is based on Ben's Proposal.
> 
Hi Michael,

Just a ping for this patch. 
The history locates at:
http://linuxppc.10917.n7.nabble.com/PATCH-v4-powerpc-Export-thread-struct-used-vr-used-vsr-to-user-space-td110147.html#a110161

If any addtional work required, please let me know.

Thanks,
- Simon

Re: [PATCH] powerpc: set used_vsr/used_vr/used_spe in sigreturn path when MSR bits are active

[Simon Guo]

On Tue, Jul 26, 2016 at 04:06:01PM +0800, wei.guo.si...@gmail.com wrote:
> From: Simon Guo 
> 
> Normally, when MSR[VSX/VR/SPE] bits = 1, the used_vsr/used_vr/used_spe
> bit have already been set. However signal frame locates at user space
> and it is controlled by user application. It is up to kernel to make
> sure used_vsr/used_vr/used_spe(in kernel)=1 and consistent with MSR
> bits.
> 
> For example, CRIU application, who utilizes sigreturn to restore
> checkpointed process, will lead to the case where MSR[VSX] bit is
> active in signal frame, but used_vsx bit is not set. (the same applies
> to VR/SPE).
> 
> This patch will reinforce this at kernel by always setting used_* bit
> when MSR related bits are active in signal frame and we are doing
> sigreturn.
> 
> This patch is based on Ben's Proposal.
> 
Hi Michael,

Just a ping for this patch. 
The history locates at:
http://linuxppc.10917.n7.nabble.com/PATCH-v4-powerpc-Export-thread-struct-used-vr-used-vsr-to-user-space-td110147.html#a110161

If any addtional work required, please let me know.

Thanks,
- Simon

Linux 4.8-rc6

[Linus Torvalds]

Things calmed down, and look very normal. About two thirds driver
updates, with half of the remainder being misc architecture updates,
and the rest being random stuff (some fs/crypto fixes etc).

Of course, just minutes after I pushed it out, David sent me the
networking pull request, so there's perhaps a reason why rc6 looks
fairly small. Oh well. I still haven't decided whether we're going to
do an rc8, but I guess I don't have to decide yet. Nothing looks
particularly bad, and it will depend on how rc7 looks.

Shortlog appended - it's small enough to easily scan to get a feel for
what's been going on.

 Linus

---

Adam Ford (2):
  ARM: dts: logicpd-torpedo-som: Provide NAND ready pin
  ARM: dts: logicpd-somlv: Fix NAND device nodes

Allen Hung (1):
  dmi-id: don't free dev structure after calling device_register

Andi Shyti (1):
  MAINTAINERS: add myself as Samsung SPI maintainer

Andreas Färber (1):
  ARM: dts: imx6sx-sabreauto: Fix misspelled property

Andy Lutomirski (1):
  virtio_console: Stop doing DMA on the stack

Andy Shevchenko (1):
  spi: pxa2xx-pci: fix ACPI-based enumeration of SPI devices

Anson Huang (1):
  ARM: imx6: add missing BM_CLPCR_BYPASS_PMIC_READY setting for imx6sx

Baoyou Xie (3):
  fix:mailbox:bcm-pdc-mailbox:mark symbols static where possible
  IB/cxgb4: Make _free_qp static to silence build warning
  virtio: mark vring_dma_dev() static

Benjamin Herrenschmidt (1):
  powerpc/xics/opal: Fix processor numbers in OPAL ICP

Chris Mason (1):
  Btrfs: remove root_log_ctx from ctx list before btrfs_sync_log returns

Christophe Jaillet (3):
  IB/hfi1: Clean up type used and casting
  IB/mlx5: Fix the size parameter to find_first_bit
  IB/hfi1: Fix the size parameter to find_first_bit

Christophe Leroy (1):
  powerpc/32: Fix again csum_partial_copy_generic()

Chuck Lever (1):
  IB/mlx5: Return EINVAL when caller specifies too many SGEs

Chunyan Zhang (1):
  arm64: use preempt_disable_notrace in _percpu_read/write

Clemens Gruber (1):
  usb: chipidea: udc: fix NULL ptr dereference in isr_setup_status_phase

Colin Ian King (2):
  iio: ensure ret is initialized to zero before entering do loop
  usb: gadget: prevent potenial null pointer dereference on skb->len

Dan Carpenter (1):
  mailbox: bcm-pdc: potential NULL dereference in pdc_shutdown()

Dan Williams (3):
  dax: fix mapping size check
  mm: fix show_smap() for zone_device-pmd ranges
  mm: fix cache mode of dax pmd mappings

Dave Gerlach (4):
  ARM: OMAP4+: hwmod: Add hwmod flag for HWMOD_OMAP4_ZERO_CLKCTRL_OFFSET
  ARM: OMAP2+: AM33XX: Add HWMOD_OMAP4_ZERO_CLKCTRL_OFFSET flag to rtc hwmod
  ARM: OMAP4+: Have _omap4_wait_target_* check for valid clkctrl_offs
  ARM: OMAP4+: CM: Remove redundant checks for clkctrl_offs of zero

Dave Jiang (1):
  libnvdimm: allow legacy (e820) pmem region to clear bad blocks

Dean Luick (1):
  IB/hfi1: Add QSFP sanity pre-check

Dirk Behme (1):
  thermal: rcar_thermal: Fix priv->zone error handling

Doug Anderson (1):
  i2c: rk3x: Restore clock settings at resume time

Elaine Zhang (1):
  regmap: drop cache if the bus transfer error

Erez Shitrit (2):
  IB/core: Fix use after free in send_leave function
  IB/ipoib: Fix memory corruption in ipoib cm mode connect flow

Eric Biggers (3):
  fscrypto: add authorization check for setting encryption policy
  fscrypto: only allow setting encryption policy on directories
  fscrypto: require write access to mount to set encryption policy

Fabio Estevam (2):
  ARM: dts: imx6qdl: Fix SPDIF regression
  usb: phy: phy-generic: Check clk_prepare_enable() error

Felipe Balbi (1):
  usb: dwc3: pci: fix build warning on !PM_SLEEP

Gavin Shan (2):
  powerpc/powernv: Fix crash on releasing compound PE
  powerpc/powernv: Fix corrupted PE allocation bitmap on releasing PE

Geert Uytterhoeven (2):
  spi: sh-msiof: Avoid invalid clock generator parameters
  i2c: Spelling s/acknowedge/acknowledge/

Gregor Boirie (2):
  tools:iio:iio_generic_buffer: fix trigger-less mode
  iio:core: fix IIO_VAL_FRACTIONAL sign handling

Gregory CLEMENT (1):
  ARM: dts: kirkwood: Fix PCIe label on OpenRD

Harish Chegondi (1):
  IB/hfi1: Make n_krcvqs be an unsigned long integer

Herbert Xu (1):
  crypto: cryptd - Use correct tfm object for AEAD tracking

Horia Geantă (1):
  crypto: caam - fix IV loading for authenc (giv)decryption

Hugo Grostabussiat (1):
  ARM: sun5i: Fix typo in trip point temperature

Icenowy Zheng (1):
  pinctrl: sunxi: fix uart1 CTS/RTS pins at PG on A23/A33

James Hartley (1):
  pinctrl: pistachio: fix mfio pll_lock pinmux

Jean Delvare (1):
  cpufreq-stats: Minor documentation fix

Johan Hovold (3):
  memory: omap-gpmc: allow probe of child nodes to fail
  ARM: dts: overo: fix gpmc nand cs0 range
  ARM: dts: overo: fix 

Linux 4.8-rc6

[Linus Torvalds]

Things calmed down, and look very normal. About two thirds driver
updates, with half of the remainder being misc architecture updates,
and the rest being random stuff (some fs/crypto fixes etc).

Of course, just minutes after I pushed it out, David sent me the
networking pull request, so there's perhaps a reason why rc6 looks
fairly small. Oh well. I still haven't decided whether we're going to
do an rc8, but I guess I don't have to decide yet. Nothing looks
particularly bad, and it will depend on how rc7 looks.

Shortlog appended - it's small enough to easily scan to get a feel for
what's been going on.

 Linus

---

Adam Ford (2):
  ARM: dts: logicpd-torpedo-som: Provide NAND ready pin
  ARM: dts: logicpd-somlv: Fix NAND device nodes

Allen Hung (1):
  dmi-id: don't free dev structure after calling device_register

Andi Shyti (1):
  MAINTAINERS: add myself as Samsung SPI maintainer

Andreas Färber (1):
  ARM: dts: imx6sx-sabreauto: Fix misspelled property

Andy Lutomirski (1):
  virtio_console: Stop doing DMA on the stack

Andy Shevchenko (1):
  spi: pxa2xx-pci: fix ACPI-based enumeration of SPI devices

Anson Huang (1):
  ARM: imx6: add missing BM_CLPCR_BYPASS_PMIC_READY setting for imx6sx

Baoyou Xie (3):
  fix:mailbox:bcm-pdc-mailbox:mark symbols static where possible
  IB/cxgb4: Make _free_qp static to silence build warning
  virtio: mark vring_dma_dev() static

Benjamin Herrenschmidt (1):
  powerpc/xics/opal: Fix processor numbers in OPAL ICP

Chris Mason (1):
  Btrfs: remove root_log_ctx from ctx list before btrfs_sync_log returns

Christophe Jaillet (3):
  IB/hfi1: Clean up type used and casting
  IB/mlx5: Fix the size parameter to find_first_bit
  IB/hfi1: Fix the size parameter to find_first_bit

Christophe Leroy (1):
  powerpc/32: Fix again csum_partial_copy_generic()

Chuck Lever (1):
  IB/mlx5: Return EINVAL when caller specifies too many SGEs

Chunyan Zhang (1):
  arm64: use preempt_disable_notrace in _percpu_read/write

Clemens Gruber (1):
  usb: chipidea: udc: fix NULL ptr dereference in isr_setup_status_phase

Colin Ian King (2):
  iio: ensure ret is initialized to zero before entering do loop
  usb: gadget: prevent potenial null pointer dereference on skb->len

Dan Carpenter (1):
  mailbox: bcm-pdc: potential NULL dereference in pdc_shutdown()

Dan Williams (3):
  dax: fix mapping size check
  mm: fix show_smap() for zone_device-pmd ranges
  mm: fix cache mode of dax pmd mappings

Dave Gerlach (4):
  ARM: OMAP4+: hwmod: Add hwmod flag for HWMOD_OMAP4_ZERO_CLKCTRL_OFFSET
  ARM: OMAP2+: AM33XX: Add HWMOD_OMAP4_ZERO_CLKCTRL_OFFSET flag to rtc hwmod
  ARM: OMAP4+: Have _omap4_wait_target_* check for valid clkctrl_offs
  ARM: OMAP4+: CM: Remove redundant checks for clkctrl_offs of zero

Dave Jiang (1):
  libnvdimm: allow legacy (e820) pmem region to clear bad blocks

Dean Luick (1):
  IB/hfi1: Add QSFP sanity pre-check

Dirk Behme (1):
  thermal: rcar_thermal: Fix priv->zone error handling

Doug Anderson (1):
  i2c: rk3x: Restore clock settings at resume time

Elaine Zhang (1):
  regmap: drop cache if the bus transfer error

Erez Shitrit (2):
  IB/core: Fix use after free in send_leave function
  IB/ipoib: Fix memory corruption in ipoib cm mode connect flow

Eric Biggers (3):
  fscrypto: add authorization check for setting encryption policy
  fscrypto: only allow setting encryption policy on directories
  fscrypto: require write access to mount to set encryption policy

Fabio Estevam (2):
  ARM: dts: imx6qdl: Fix SPDIF regression
  usb: phy: phy-generic: Check clk_prepare_enable() error

Felipe Balbi (1):
  usb: dwc3: pci: fix build warning on !PM_SLEEP

Gavin Shan (2):
  powerpc/powernv: Fix crash on releasing compound PE
  powerpc/powernv: Fix corrupted PE allocation bitmap on releasing PE

Geert Uytterhoeven (2):
  spi: sh-msiof: Avoid invalid clock generator parameters
  i2c: Spelling s/acknowedge/acknowledge/

Gregor Boirie (2):
  tools:iio:iio_generic_buffer: fix trigger-less mode
  iio:core: fix IIO_VAL_FRACTIONAL sign handling

Gregory CLEMENT (1):
  ARM: dts: kirkwood: Fix PCIe label on OpenRD

Harish Chegondi (1):
  IB/hfi1: Make n_krcvqs be an unsigned long integer

Herbert Xu (1):
  crypto: cryptd - Use correct tfm object for AEAD tracking

Horia Geantă (1):
  crypto: caam - fix IV loading for authenc (giv)decryption

Hugo Grostabussiat (1):
  ARM: sun5i: Fix typo in trip point temperature

Icenowy Zheng (1):
  pinctrl: sunxi: fix uart1 CTS/RTS pins at PG on A23/A33

James Hartley (1):
  pinctrl: pistachio: fix mfio pll_lock pinmux

Jean Delvare (1):
  cpufreq-stats: Minor documentation fix

Johan Hovold (3):
  memory: omap-gpmc: allow probe of child nodes to fail
  ARM: dts: overo: fix gpmc nand cs0 range
  ARM: dts: overo: fix 

Re: [PATCH v4 3/3] drm/mediatek: fix the wrong pixel clock when resolution is 4K

[CK Hu]

Hi, Bibby:

Sorry for the late reply.

On Wed, 2016-08-17 at 14:58 +0800, Bibby Hsieh wrote:
> From: Junzhi Zhao 
> 
> Pixel clock should be 297MHz when resolution is 4K.
> 

>From the code you modified, I think title should be: "Enlarge pll_rate
range from (, ) to (, )"

In description, you can explain the pll_rate for 4K and this enlargement
could support more resolution include 4K (Not only 4K).

> Signed-off-by: Junzhi Zhao 
> Signed-off-by: Bibby Hsieh 
> ---
>  drivers/gpu/drm/mediatek/mtk_dpi.c |9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
> b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index 0186e50..90fb831 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -432,11 +432,16 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
>   unsigned long pll_rate;
>   unsigned int factor;
>  
> + /* let pll_rate can fix the valid range of tvdpll (1G~2GHz) */
>   pix_rate = 1000UL * mode->clock;
> - if (mode->clock <= 74000)
> + if (mode->clock <= 27000)
> + factor = 16 * 3;
> + else if (mode->clock <= 84000)
>   factor = 8 * 3;
> - else
> + else if (mode->clock <= 167000)
>   factor = 4 * 3;
> + else
> + factor = 2 * 3;
>   pll_rate = pix_rate * factor;
>  
>   dev_dbg(dpi->dev, "Want PLL %lu Hz, pixel clock %lu Hz\n",

Regards,
CK

Re: [PATCH v4 3/3] drm/mediatek: fix the wrong pixel clock when resolution is 4K

[CK Hu]

Hi, Bibby:

Sorry for the late reply.

On Wed, 2016-08-17 at 14:58 +0800, Bibby Hsieh wrote:
> From: Junzhi Zhao 
> 
> Pixel clock should be 297MHz when resolution is 4K.
> 

>From the code you modified, I think title should be: "Enlarge pll_rate
range from (, ) to (, )"

In description, you can explain the pll_rate for 4K and this enlargement
could support more resolution include 4K (Not only 4K).

> Signed-off-by: Junzhi Zhao 
> Signed-off-by: Bibby Hsieh 
> ---
>  drivers/gpu/drm/mediatek/mtk_dpi.c |9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
> b/drivers/gpu/drm/mediatek/mtk_dpi.c
> index 0186e50..90fb831 100644
> --- a/drivers/gpu/drm/mediatek/mtk_dpi.c
> +++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
> @@ -432,11 +432,16 @@ static int mtk_dpi_set_display_mode(struct mtk_dpi *dpi,
>   unsigned long pll_rate;
>   unsigned int factor;
>  
> + /* let pll_rate can fix the valid range of tvdpll (1G~2GHz) */
>   pix_rate = 1000UL * mode->clock;
> - if (mode->clock <= 74000)
> + if (mode->clock <= 27000)
> + factor = 16 * 3;
> + else if (mode->clock <= 84000)
>   factor = 8 * 3;
> - else
> + else if (mode->clock <= 167000)
>   factor = 4 * 3;
> + else
> + factor = 2 * 3;
>   pll_rate = pix_rate * factor;
>  
>   dev_dbg(dpi->dev, "Want PLL %lu Hz, pixel clock %lu Hz\n",

Regards,
CK

RE: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)

[Jun Li]

> -Original Message-
> From: Guenter Roeck [mailto:gro...@google.com]
> Sent: Monday, September 12, 2016 10:24 AM
> To: Jun Li 
> Cc: Guenter Roeck ; Felipe Balbi
> ; Chandra Sekhar Anagani
> ; Bruce Ashfield
> ; Bin Gao ; Pranav Tipnis
> ; Heikki Krogerus
> ; linux-kernel@vger.kernel.org; linux-
> u...@vger.kernel.org
> Subject: Re: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)
> 
> On Sun, Sep 11, 2016 at 7:16 PM, Jun Li  wrote:
> > Hi Guenter
> >
> >> -Original Message-
> >> From: Guenter Roeck [mailto:gro...@google.com]
> >> Sent: Saturday, September 10, 2016 10:23 AM
> >> To: Jun Li 
> >> Cc: Guenter Roeck ; Felipe Balbi
> >> ; Chandra Sekhar Anagani
> >> ; Bruce Ashfield
> >> ; Bin Gao ; Pranav
> >> Tipnis ; Heikki Krogerus
> >> ; linux-kernel@vger.kernel.org;
> >> linux- u...@vger.kernel.org
> >> Subject: Re: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager
> >> (tcpm)
> >>
> >> On Fri, Sep 9, 2016 at 5:26 PM, Jun Li  wrote:
> >> > Hi Guenter,
> >> >
> >> >> -Original Message-
> >> >> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> >> >> ow...@vger.kernel.org] On Behalf Of Guenter Roeck
> >> >> Sent: Wednesday, August 24, 2016 5:11 AM
> >> >> To: Felipe Balbi 
> >> >> Cc: Chandra Sekhar Anagani ;
> >> >> Bruce Ashfield ; Bin Gao
> >> >> ; Pranav Tipnis ;
> >> >> Heikki Krogerus ;
> >> >> linux-kernel@vger.kernel.org;
> >> >> linux- u...@vger.kernel.org; Guenter Roeck 
> >> >> Subject: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager
> >> >> (tcpm)
> >> >>
> >> >> This driver implements the USB Type-C Power Delivery state machine
> >> >> for both source and sink ports. Alternate mode support is not
> >> >> fully implemented.
> >> >>
> >> >> The driver attaches to the USB Type-C class code implemented in
> >> >> the following patches.
> >> >>
> >> >>   usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C
> PHY
> >> >>   usb: USB Type-C connector class
> >> >>
> >> >> This driver only implements the state machine. Lower level drivers
> >> >> are responsible for
> >> >> - Reporting VBUS status and activating VBUS
> >> >> - Setting CC lines and providing CC line status
> >> >> - Setting line polarity
> >> >> - Activating and deactivating VCONN
> >> >> - Setting the current limit
> >> >> - Activating and deactivating PD message transfers
> >> >> - Sending and receiving PD messages
> >> >>
> >> >> The driver provides both a functional API as well as callbacks for
> >> >> lower level drivers.
> >> >>
> >> >> Signed-off-by: Guenter Roeck 
> >> >> ---
> >> >
> >> > A specific question, if power sink wants to request a new power
> >> > level after SNK_READY, how to handle it with this tcpm?
> >> >
> >>
> >> So far I have considered the required power level to be static, based
> >> on our curent implementations. That should be easy to change, though,
> >> with an additional API function, to be called from a low level driver.
> >> Do you have that requirement, and would such a function meet your
> needs ?
> >>
> >
> > So you are going to make port->tcpc->config to be dynamic to meet my
> need?
> >
> What would that help ? How would tcpm get informed that the power
> requirements changed without an API function telling it that power
> requirements changed ?

Of cos I agree an additional API is required, I am just wondering how
that API will be look like, as current request build is according to
port->tcpc->config.

Li Jun  
> 
> Guenter

RE: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)

[Jun Li]

> -Original Message-
> From: Guenter Roeck [mailto:gro...@google.com]
> Sent: Monday, September 12, 2016 10:24 AM
> To: Jun Li 
> Cc: Guenter Roeck ; Felipe Balbi
> ; Chandra Sekhar Anagani
> ; Bruce Ashfield
> ; Bin Gao ; Pranav Tipnis
> ; Heikki Krogerus
> ; linux-kernel@vger.kernel.org; linux-
> u...@vger.kernel.org
> Subject: Re: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)
> 
> On Sun, Sep 11, 2016 at 7:16 PM, Jun Li  wrote:
> > Hi Guenter
> >
> >> -Original Message-
> >> From: Guenter Roeck [mailto:gro...@google.com]
> >> Sent: Saturday, September 10, 2016 10:23 AM
> >> To: Jun Li 
> >> Cc: Guenter Roeck ; Felipe Balbi
> >> ; Chandra Sekhar Anagani
> >> ; Bruce Ashfield
> >> ; Bin Gao ; Pranav
> >> Tipnis ; Heikki Krogerus
> >> ; linux-kernel@vger.kernel.org;
> >> linux- u...@vger.kernel.org
> >> Subject: Re: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager
> >> (tcpm)
> >>
> >> On Fri, Sep 9, 2016 at 5:26 PM, Jun Li  wrote:
> >> > Hi Guenter,
> >> >
> >> >> -Original Message-
> >> >> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
> >> >> ow...@vger.kernel.org] On Behalf Of Guenter Roeck
> >> >> Sent: Wednesday, August 24, 2016 5:11 AM
> >> >> To: Felipe Balbi 
> >> >> Cc: Chandra Sekhar Anagani ;
> >> >> Bruce Ashfield ; Bin Gao
> >> >> ; Pranav Tipnis ;
> >> >> Heikki Krogerus ;
> >> >> linux-kernel@vger.kernel.org;
> >> >> linux- u...@vger.kernel.org; Guenter Roeck 
> >> >> Subject: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager
> >> >> (tcpm)
> >> >>
> >> >> This driver implements the USB Type-C Power Delivery state machine
> >> >> for both source and sink ports. Alternate mode support is not
> >> >> fully implemented.
> >> >>
> >> >> The driver attaches to the USB Type-C class code implemented in
> >> >> the following patches.
> >> >>
> >> >>   usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C
> PHY
> >> >>   usb: USB Type-C connector class
> >> >>
> >> >> This driver only implements the state machine. Lower level drivers
> >> >> are responsible for
> >> >> - Reporting VBUS status and activating VBUS
> >> >> - Setting CC lines and providing CC line status
> >> >> - Setting line polarity
> >> >> - Activating and deactivating VCONN
> >> >> - Setting the current limit
> >> >> - Activating and deactivating PD message transfers
> >> >> - Sending and receiving PD messages
> >> >>
> >> >> The driver provides both a functional API as well as callbacks for
> >> >> lower level drivers.
> >> >>
> >> >> Signed-off-by: Guenter Roeck 
> >> >> ---
> >> >
> >> > A specific question, if power sink wants to request a new power
> >> > level after SNK_READY, how to handle it with this tcpm?
> >> >
> >>
> >> So far I have considered the required power level to be static, based
> >> on our curent implementations. That should be easy to change, though,
> >> with an additional API function, to be called from a low level driver.
> >> Do you have that requirement, and would such a function meet your
> needs ?
> >>
> >
> > So you are going to make port->tcpc->config to be dynamic to meet my
> need?
> >
> What would that help ? How would tcpm get informed that the power
> requirements changed without an API function telling it that power
> requirements changed ?

Of cos I agree an additional API is required, I am just wondering how
that API will be look like, as current request build is according to
port->tcpc->config.

Li Jun  
> 
> Guenter

[GIT] Networking

[David Miller]

Mostly small sets of driver fixes scattered all over the place.

1) Mediatek driver fixes from Sean Wang.  Forward port not written
   correctly during TX map, missed handling of EPROBE_DEFER, and
   mistaken use of put_page() instead of skb_free_frag().

2) Fix socket double-free in KCM code, from WANG Cong.

3) QED driver fixes from Sudarsana Reddy Kalluru, including a fix
   for using the dcbx buffers before initializing them.

4) Mellanox Switch driver fixes from Jiri Pirko, including a fix for
   double fib removals and an error handling fix in
   mlxsw_sp_module_init().

5) Fix kernel panic when enabling LLDP in i40e driver, from Dave
   Ertman.

6) Fix padding of TSO packets in thunderx driver, from Sunil Goutham.

7) TCP's rcv_wup not initialized properly when using fastopen, from
   Neal Cardwell.

8) Don't use uninitialized flow keys in flow dissector, from Gao
   Feng.

9) Use after free in l2tp module unload, from Sabrina Dubroca.

10) Fix interrupt registry ordering issues in smsc911x driver, from
Jeremy Linton.

11) Fix crashes in bonding having to do with enslaving and rx_handler,
from Mahesh Bandewar.

12) AF_UNIX deadlock fixes from Linus.

13) In mlx5 driver, don't read skb->xmit_mode after it might have been
freed from the TX reclaim path.  From Tariq Toukan.

14) Fix a bug from 2015 in TCP Yeah where the congestion window does
not increase, from Artem Germanov.

15) Don't pad frames on receive in NFP driver, from Jakub Kicinski.

16) Fix chunk fragmenting in SCTP wrt. GSO, from Marcelo Ricardo
Leitner.

17) Fix deletion of VRF routes, from Mark Tomlinson.

18) Fix device refcount leak when DAD fails in ipv6, from Wei Yongjun.

Please pull, thanks a lot!

The following changes since commit e4e98c460ad38c78498622a164fd5ef09a2dc9cb:

  Merge tag 'hwmon-for-linus-v4.8-rc5' of 
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging (2016-08-29 
19:12:35 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net 

for you to fetch changes up to 373df3131aa83bd3e0ea7cd15be92d942d75fc72:

  Merge branch 'mlx4-fixes' (2016-09-11 19:40:26 -0700)


Alexey Kodanev (1):
  net/xfrm_input: fix possible NULL deref of tunnel.ip6->parms.i_key

Andy Gospodarek (1):
  MAINTAINERS: update to working email address

Arend Van Spriel (1):
  brcmfmac: avoid potential stack overflow in brcmf_cfg80211_start_ap()

Arik Nemtsov (1):
  mac80211: TDLS: don't require beaconing for AP BW

Artem Germanov (1):
  tcp: cwnd does not increase in TCP YeAH

Ashok Raj Nagarajan (1):
  ath10k: fix get rx_status from htt context

Bodong Wang (1):
  net/mlx5e: Move an_disable_cap bit to a new position

Cathy Luo (1):
  mwifiex: fix large amsdu packets causing firmware hang

Chris Brandt (1):
  net: ethernet: renesas: sh_eth: add POST registers for rz

Dave Ertman (1):
  i40e: Fix kernel panic on enable/disable LLDP

Dave Jones (1):
  ipv6: release dst in ping_v6_sendmsg

David Ahern (1):
  xfrm: Only add l3mdev oif to dst lookups

David S. Miller (15):
  Merge tag 'mac80211-for-davem-2016-08-30' of 
git://git.kernel.org/.../jberg/mac80211
  Merge git://git.kernel.org/.../pablo/nf
  Merge branch 'mediatek-fixes'
  Merge branch 'qed-fixes'
  Merge branch 'mlxsw-fixes'
  Merge tag 'wireless-drivers-for-davem-2016-08-29' of 
git://git.kernel.org/.../kvalo/wireless-drivers
  Merge branch 'thunderx-fixes'
  Merge branch 'smsc911x-fixes'
  Merge branch 'vxlan-fixes'
  Merge branch 'master' of git://git.kernel.org/.../klassert/ipsec
  Merge branch 'mlx5-fixes'
  Merge branch 'nfp-fixes'
  Merge branch 'mlxsw-fixes'
  Merge tag 'wireless-drivers-for-davem-2016-09-08' of 
git://git.kernel.org/.../kvalo/wireless-drivers
  Merge branch 'mlx4-fixes'

Davide Caratti (1):
  bridge: re-introduce 'fix parsing of MLDv2 reports'

Eli Cooper (1):
  ipv6: Don't unset flowi6_proto in ipxip6_tnl_xmit()

Emmanuel Grumbach (2):
  iwlwifi: mvm: consider P2p device type for firmware dump triggers
  iwlwifi: mvm: don't use ret when not initialised

Eric Dumazet (1):
  tcp: fastopen: avoid negative sk_forward_alloc

Felix Fietkau (2):
  ath9k: fix client mode beacon configuration
  ath9k: fix using sta->drv_priv before initializing it

Florian Fainelli (1):
  MAINTAINERS: Update CPMAC email address

Gal Pressman (3):
  net/mlx5e: Prevent casting overflow
  net/mlx5e: Fix global PFC counters replication
  net/mlx5e: Fix parsing of vlan packets when updating lro header

Gao Feng (1):
  rps: flow_dissector: Fix uninitialized flow_keys used in __skb_get_hash 
possibly

Giedrius Statkevičius (1):
  ath9k: bring back direction setting in ath9k_{start_stop}

Guilherme G. Piccoli (1):
  bnx2x: don't reset chip on cleanup if PCI function is offline

Helmut 

[GIT] Networking

[David Miller]

Mostly small sets of driver fixes scattered all over the place.

1) Mediatek driver fixes from Sean Wang.  Forward port not written
   correctly during TX map, missed handling of EPROBE_DEFER, and
   mistaken use of put_page() instead of skb_free_frag().

2) Fix socket double-free in KCM code, from WANG Cong.

3) QED driver fixes from Sudarsana Reddy Kalluru, including a fix
   for using the dcbx buffers before initializing them.

4) Mellanox Switch driver fixes from Jiri Pirko, including a fix for
   double fib removals and an error handling fix in
   mlxsw_sp_module_init().

5) Fix kernel panic when enabling LLDP in i40e driver, from Dave
   Ertman.

6) Fix padding of TSO packets in thunderx driver, from Sunil Goutham.

7) TCP's rcv_wup not initialized properly when using fastopen, from
   Neal Cardwell.

8) Don't use uninitialized flow keys in flow dissector, from Gao
   Feng.

9) Use after free in l2tp module unload, from Sabrina Dubroca.

10) Fix interrupt registry ordering issues in smsc911x driver, from
Jeremy Linton.

11) Fix crashes in bonding having to do with enslaving and rx_handler,
from Mahesh Bandewar.

12) AF_UNIX deadlock fixes from Linus.

13) In mlx5 driver, don't read skb->xmit_mode after it might have been
freed from the TX reclaim path.  From Tariq Toukan.

14) Fix a bug from 2015 in TCP Yeah where the congestion window does
not increase, from Artem Germanov.

15) Don't pad frames on receive in NFP driver, from Jakub Kicinski.

16) Fix chunk fragmenting in SCTP wrt. GSO, from Marcelo Ricardo
Leitner.

17) Fix deletion of VRF routes, from Mark Tomlinson.

18) Fix device refcount leak when DAD fails in ipv6, from Wei Yongjun.

Please pull, thanks a lot!

The following changes since commit e4e98c460ad38c78498622a164fd5ef09a2dc9cb:

  Merge tag 'hwmon-for-linus-v4.8-rc5' of 
git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging (2016-08-29 
19:12:35 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net 

for you to fetch changes up to 373df3131aa83bd3e0ea7cd15be92d942d75fc72:

  Merge branch 'mlx4-fixes' (2016-09-11 19:40:26 -0700)


Alexey Kodanev (1):
  net/xfrm_input: fix possible NULL deref of tunnel.ip6->parms.i_key

Andy Gospodarek (1):
  MAINTAINERS: update to working email address

Arend Van Spriel (1):
  brcmfmac: avoid potential stack overflow in brcmf_cfg80211_start_ap()

Arik Nemtsov (1):
  mac80211: TDLS: don't require beaconing for AP BW

Artem Germanov (1):
  tcp: cwnd does not increase in TCP YeAH

Ashok Raj Nagarajan (1):
  ath10k: fix get rx_status from htt context

Bodong Wang (1):
  net/mlx5e: Move an_disable_cap bit to a new position

Cathy Luo (1):
  mwifiex: fix large amsdu packets causing firmware hang

Chris Brandt (1):
  net: ethernet: renesas: sh_eth: add POST registers for rz

Dave Ertman (1):
  i40e: Fix kernel panic on enable/disable LLDP

Dave Jones (1):
  ipv6: release dst in ping_v6_sendmsg

David Ahern (1):
  xfrm: Only add l3mdev oif to dst lookups

David S. Miller (15):
  Merge tag 'mac80211-for-davem-2016-08-30' of 
git://git.kernel.org/.../jberg/mac80211
  Merge git://git.kernel.org/.../pablo/nf
  Merge branch 'mediatek-fixes'
  Merge branch 'qed-fixes'
  Merge branch 'mlxsw-fixes'
  Merge tag 'wireless-drivers-for-davem-2016-08-29' of 
git://git.kernel.org/.../kvalo/wireless-drivers
  Merge branch 'thunderx-fixes'
  Merge branch 'smsc911x-fixes'
  Merge branch 'vxlan-fixes'
  Merge branch 'master' of git://git.kernel.org/.../klassert/ipsec
  Merge branch 'mlx5-fixes'
  Merge branch 'nfp-fixes'
  Merge branch 'mlxsw-fixes'
  Merge tag 'wireless-drivers-for-davem-2016-09-08' of 
git://git.kernel.org/.../kvalo/wireless-drivers
  Merge branch 'mlx4-fixes'

Davide Caratti (1):
  bridge: re-introduce 'fix parsing of MLDv2 reports'

Eli Cooper (1):
  ipv6: Don't unset flowi6_proto in ipxip6_tnl_xmit()

Emmanuel Grumbach (2):
  iwlwifi: mvm: consider P2p device type for firmware dump triggers
  iwlwifi: mvm: don't use ret when not initialised

Eric Dumazet (1):
  tcp: fastopen: avoid negative sk_forward_alloc

Felix Fietkau (2):
  ath9k: fix client mode beacon configuration
  ath9k: fix using sta->drv_priv before initializing it

Florian Fainelli (1):
  MAINTAINERS: Update CPMAC email address

Gal Pressman (3):
  net/mlx5e: Prevent casting overflow
  net/mlx5e: Fix global PFC counters replication
  net/mlx5e: Fix parsing of vlan packets when updating lro header

Gao Feng (1):
  rps: flow_dissector: Fix uninitialized flow_keys used in __skb_get_hash 
possibly

Giedrius Statkevičius (1):
  ath9k: bring back direction setting in ath9k_{start_stop}

Guilherme G. Piccoli (1):
  bnx2x: don't reset chip on cleanup if PCI function is offline

Helmut 

Re: [PATCH 0/9] tty: tty_struct dependency clean-ups

[Rob Herring]

On Sun, Sep 11, 2016 at 4:14 PM, One Thousand Gnomes
 wrote:
> On Fri,  9 Sep 2016 17:37:01 -0500
> Rob Herring  wrote:
>
>> This patch series removes or prepares to remove some of the dependencies
>> on tty_struct within tty_port drivers. This will allow using tty_ports
>> directly for so called UART slave devices.
>
> You can create a tty_struct kernel side with the two tiny changes I
> posted before. Why do you want to do invasive tree wide changes when you
> can do simple ones ?

Well, I don't want to do invasive changes, but I thought the idea was
to use tty_port struct without a tty_struct.

>> Next up after this are moving some functions to the tty_port ops. I've
>> got some WIP patches for some of that, but nothing ready to send out
>> quite yet.
>
> I think before this lot happens you need to decide where these structures
> belong. Termios and termios_locked for example could live in the tty_port
> as the physical tty is incapable of having multiple sets of terminal data
> at once.

I was planning to keep termios out of tty_port and make clients of
tty_port carry it if for nothing else not quite understanding all the
details around the lifetime, init and locking of it. If there's always
a tty_struct then there's not much point moving it other than which
struct makes more sense. But that would cause some churn.

Rob

Re: [PATCH 0/9] tty: tty_struct dependency clean-ups

[Rob Herring]

On Sun, Sep 11, 2016 at 4:14 PM, One Thousand Gnomes
 wrote:
> On Fri,  9 Sep 2016 17:37:01 -0500
> Rob Herring  wrote:
>
>> This patch series removes or prepares to remove some of the dependencies
>> on tty_struct within tty_port drivers. This will allow using tty_ports
>> directly for so called UART slave devices.
>
> You can create a tty_struct kernel side with the two tiny changes I
> posted before. Why do you want to do invasive tree wide changes when you
> can do simple ones ?

Well, I don't want to do invasive changes, but I thought the idea was
to use tty_port struct without a tty_struct.

>> Next up after this are moving some functions to the tty_port ops. I've
>> got some WIP patches for some of that, but nothing ready to send out
>> quite yet.
>
> I think before this lot happens you need to decide where these structures
> belong. Termios and termios_locked for example could live in the tty_port
> as the physical tty is incapable of having multiple sets of terminal data
> at once.

I was planning to keep termios out of tty_port and make clients of
tty_port carry it if for nothing else not quite understanding all the
details around the lifetime, init and locking of it. If there's always
a tty_struct then there's not much point moving it other than which
struct makes more sense. But that would cause some churn.

Rob

linux-next: manual merge of the tip tree with the arm64 tree

[Stephen Rothwell]

Hi all,

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

  include/linux/jump_label.h

between commit:

  ef0da55a84a3 ("jump_labels: Allow array initialisers")

from the arm64 tree and commit:

  b8fb03785d4d ("locking/static_keys: Provide DECLARE and well as DEFINE 
macros")

from the tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/linux/jump_label.h
index a534c7f15a61,595fb46213fc..
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@@ -272,16 -273,9 +275,19 @@@ struct static_key_false 
  #define DEFINE_STATIC_KEY_FALSE(name) \
struct static_key_false name = STATIC_KEY_FALSE_INIT
  
+ #define DECLARE_STATIC_KEY_FALSE(name)\
+   extern struct static_key_false name
+ 
 +#define DEFINE_STATIC_KEY_ARRAY_TRUE(name, count) \
 +  struct static_key_true name[count] = {  \
 +  [0 ... (count) - 1] = STATIC_KEY_TRUE_INIT, \
 +  }
 +
 +#define DEFINE_STATIC_KEY_ARRAY_FALSE(name, count)\
 +  struct static_key_false name[count] = { \
 +  [0 ... (count) - 1] = STATIC_KEY_FALSE_INIT,\
 +  }
 +
  extern bool wrong_branch_error(void);
  
  #define static_key_enabled(x) 
\

linux-next: manual merge of the tip tree with the arm64 tree

[Stephen Rothwell]

Hi all,

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

  include/linux/jump_label.h

between commit:

  ef0da55a84a3 ("jump_labels: Allow array initialisers")

from the arm64 tree and commit:

  b8fb03785d4d ("locking/static_keys: Provide DECLARE and well as DEFINE 
macros")

from the tip tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc include/linux/jump_label.h
index a534c7f15a61,595fb46213fc..
--- a/include/linux/jump_label.h
+++ b/include/linux/jump_label.h
@@@ -272,16 -273,9 +275,19 @@@ struct static_key_false 
  #define DEFINE_STATIC_KEY_FALSE(name) \
struct static_key_false name = STATIC_KEY_FALSE_INIT
  
+ #define DECLARE_STATIC_KEY_FALSE(name)\
+   extern struct static_key_false name
+ 
 +#define DEFINE_STATIC_KEY_ARRAY_TRUE(name, count) \
 +  struct static_key_true name[count] = {  \
 +  [0 ... (count) - 1] = STATIC_KEY_TRUE_INIT, \
 +  }
 +
 +#define DEFINE_STATIC_KEY_ARRAY_FALSE(name, count)\
 +  struct static_key_false name[count] = { \
 +  [0 ... (count) - 1] = STATIC_KEY_FALSE_INIT,\
 +  }
 +
  extern bool wrong_branch_error(void);
  
  #define static_key_enabled(x) 
\

Re: linux-next: manual merge of the kbuild tree with Linus' tree

[Nicholas Piggin]

On Mon, 12 Sep 2016 11:32:24 +1000
Stephen Rothwell  wrote:

> Hi Michal,
> 
> Today's linux-next merge of the kbuild tree got a conflict in:
> 
>   arch/Kconfig
> 
> between commit:
> 
>   0f60a8efe400 ("mm: Implement stack frame object validation")
> 
> from Linus' tree and commits:
> 
>   a5967db9af51 ("kbuild: allow architectures to use thin archives instead of 
> ld -r")
>   b67067f1176d ("kbuild: allow archs to select link dead code/data 
> elimination")
> 
> from the kbuild tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 

Thanks Stephen, this should be a trivial conflict. Also you wrote one
of the patches :)

Question, what is the best way to merge dependent patches? Considering
they will need a good amount of architecture testing, I think they will
have to go via arch trees. But it also does not make sense to merge these
kbuild changes upstream first, without having tested them.

Thanks,
Nick

Re: linux-next: manual merge of the kbuild tree with Linus' tree

[Nicholas Piggin]

On Mon, 12 Sep 2016 11:32:24 +1000
Stephen Rothwell  wrote:

> Hi Michal,
> 
> Today's linux-next merge of the kbuild tree got a conflict in:
> 
>   arch/Kconfig
> 
> between commit:
> 
>   0f60a8efe400 ("mm: Implement stack frame object validation")
> 
> from Linus' tree and commits:
> 
>   a5967db9af51 ("kbuild: allow architectures to use thin archives instead of 
> ld -r")
>   b67067f1176d ("kbuild: allow archs to select link dead code/data 
> elimination")
> 
> from the kbuild tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
> 

Thanks Stephen, this should be a trivial conflict. Also you wrote one
of the patches :)

Question, what is the best way to merge dependent patches? Considering
they will need a good amount of architecture testing, I think they will
have to go via arch trees. But it also does not make sense to merge these
kbuild changes upstream first, without having tested them.

Thanks,
Nick

[PATCH] iommu/vt-d: Fix the size calculation of pasid table

[Xunlei Pang]

According to the vt-d spec, the size of pasid (state) entry is 8B
which equals 3 in power of 2, the number of pasid (state) entries
is (ecap_pss + 1) in power of 2.

Thus the right size of pasid (state) table in power of 2 should be
ecap_pss(iommu->ecap) plus "1+3=4" other than 7.

Signed-off-by: Xunlei Pang 
---
 drivers/iommu/intel-svm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/intel-svm.c b/drivers/iommu/intel-svm.c
index 8ebb353..cfa75c2 100644
--- a/drivers/iommu/intel-svm.c
+++ b/drivers/iommu/intel-svm.c
@@ -39,7 +39,7 @@ int intel_svm_alloc_pasid_tables(struct intel_iommu *iommu)
struct page *pages;
int order;
 
-   order = ecap_pss(iommu->ecap) + 7 - PAGE_SHIFT;
+   order = ecap_pss(iommu->ecap) + 4 - PAGE_SHIFT;
if (order < 0)
order = 0;
 
-- 
1.8.3.1

[PATCH] iommu/vt-d: Fix the size calculation of pasid table

[Xunlei Pang]

According to the vt-d spec, the size of pasid (state) entry is 8B
which equals 3 in power of 2, the number of pasid (state) entries
is (ecap_pss + 1) in power of 2.

Thus the right size of pasid (state) table in power of 2 should be
ecap_pss(iommu->ecap) plus "1+3=4" other than 7.

Signed-off-by: Xunlei Pang 
---
 drivers/iommu/intel-svm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/intel-svm.c b/drivers/iommu/intel-svm.c
index 8ebb353..cfa75c2 100644
--- a/drivers/iommu/intel-svm.c
+++ b/drivers/iommu/intel-svm.c
@@ -39,7 +39,7 @@ int intel_svm_alloc_pasid_tables(struct intel_iommu *iommu)
struct page *pages;
int order;
 
-   order = ecap_pss(iommu->ecap) + 7 - PAGE_SHIFT;
+   order = ecap_pss(iommu->ecap) + 4 - PAGE_SHIFT;
if (order < 0)
order = 0;
 
-- 
1.8.3.1

Re: [PATCH] cpuset: handle race between CPU hotplug and cpuset_hotplug_work

[Zefan Li]

Cc: Tejun

On 2016/9/9 8:41, Joonwoo Park wrote:
> Discrepancy between cpu_online_mask and cpuset's effective CPU masks on
> cpuset hierarchy is inevitable since cpuset defers updating of
> effective CPU masks with workqueue while nothing prevents system from
> doing CPU hotplug.  For that reason guarantee_online_cpus() walks up
> the cpuset hierarchy until it finds intersection under the assumption
> that top cpuset's effective CPU mask intersects with cpu_online_mask
> even under such race.
> 
> However a sequence of CPU hotplugs can open a time window which is none
> of effective CPUs in the top cpuset intersects with cpu_online_mask.
> 
> For example when there are 4 possible CPUs 0-3 where only CPU0 is online:
> 
>     ===
>cpu_online_mask   top_cpuset.effective_cpus
>     ===
>echo 1 > cpu2/online.
>CPU hotplug notifier woke up hotplug work but not yet scheduled.
>   [0,2] [0]
> 
>echo 0 > cpu0/online.
>The workqueue is still runnable.
>   [2]   [0]
>     ===
> 
>   Now there is no intersection between cpu_online_mask and
>   top_cpuset.effective_cpus.  Thus invoking sys_sched_setaffinity() at
>   this moment can cause following:
> 
>Unable to handle kernel NULL pointer dereference at virtual address 
> 00d0
>[ cut here ]
>Kernel BUG at ffc0001389b0 [verbose debug info unavailable]
>Internal error: Oops - BUG: 9605 [#1] PREEMPT SMP
>Modules linked in:
>CPU: 2 PID: 1420 Comm: taskset Tainted: GW   4.4.8+ #98
>task: ffc06a5c4880 ti: ffc06e124000 task.ti: ffc06e124000
>PC is at guarantee_online_cpus+0x2c/0x58
>LR is at cpuset_cpus_allowed+0x4c/0x6c
>
>Process taskset (pid: 1420, stack limit = 0xffc06e124020)
>Call trace:
>[] guarantee_online_cpus+0x2c/0x58
>[] cpuset_cpus_allowed+0x4c/0x6c
>[] sched_setaffinity+0xc0/0x1ac
>[] SyS_sched_setaffinity+0x98/0xac
>[] el0_svc_naked+0x24/0x28
> 
> The top cpuset's effective_cpus are guaranteed to be identical to online
> CPUs eventually.  Hence fall back to online CPU mask when there is no
> intersection between top cpuset's effective_cpus and online CPU mask.
> 
> Signed-off-by: Joonwoo Park 
> Cc: Li Zefan 
> Cc: cgro...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org

Thanks for fixing this!

Acked-by: Zefan Li 
Cc:  # 3.17+

> ---
>  kernel/cpuset.c | 17 ++---
>  1 file changed, 14 insertions(+), 3 deletions(-)
> 
> diff --git a/kernel/cpuset.c b/kernel/cpuset.c
> index c7fd277..b5d2b73 100644
> --- a/kernel/cpuset.c
> +++ b/kernel/cpuset.c
> @@ -325,8 +325,7 @@ static struct file_system_type cpuset_fs_type = {
>  /*
>   * Return in pmask the portion of a cpusets's cpus_allowed that
>   * are online.  If none are online, walk up the cpuset hierarchy
> - * until we find one that does have some online cpus.  The top
> - * cpuset always has some cpus online.
> + * until we find one that does have some online cpus.
>   *
>   * One way or another, we guarantee to return some non-empty subset
>   * of cpu_online_mask.
> @@ -335,8 +334,20 @@ static struct file_system_type cpuset_fs_type = {
>   */
>  static void guarantee_online_cpus(struct cpuset *cs, struct cpumask *pmask)
>  {
> - while (!cpumask_intersects(cs->effective_cpus, cpu_online_mask))
> + while (!cpumask_intersects(cs->effective_cpus, cpu_online_mask)) {
>   cs = parent_cs(cs);
> + if (unlikely(!cs)) {
> + /*
> +  * The top cpuset doesn't have any online cpu in
> +  * consequence of race between cpuset_hotplug_work
> +  * and cpu hotplug notifier.  But we know the top
> +  * cpuset's effective_cpus is on its way to be same
> +  * with online cpus mask.
> +  */
> + cpumask_copy(pmask, cpu_online_mask);
> + return;
> + }
> + }
>   cpumask_and(pmask, cs->effective_cpus, cpu_online_mask);
>  }
>  
> 

Re: [PATCH] cpuset: handle race between CPU hotplug and cpuset_hotplug_work

[Zefan Li]

Cc: Tejun

On 2016/9/9 8:41, Joonwoo Park wrote:
> Discrepancy between cpu_online_mask and cpuset's effective CPU masks on
> cpuset hierarchy is inevitable since cpuset defers updating of
> effective CPU masks with workqueue while nothing prevents system from
> doing CPU hotplug.  For that reason guarantee_online_cpus() walks up
> the cpuset hierarchy until it finds intersection under the assumption
> that top cpuset's effective CPU mask intersects with cpu_online_mask
> even under such race.
> 
> However a sequence of CPU hotplugs can open a time window which is none
> of effective CPUs in the top cpuset intersects with cpu_online_mask.
> 
> For example when there are 4 possible CPUs 0-3 where only CPU0 is online:
> 
>     ===
>cpu_online_mask   top_cpuset.effective_cpus
>     ===
>echo 1 > cpu2/online.
>CPU hotplug notifier woke up hotplug work but not yet scheduled.
>   [0,2] [0]
> 
>echo 0 > cpu0/online.
>The workqueue is still runnable.
>   [2]   [0]
>     ===
> 
>   Now there is no intersection between cpu_online_mask and
>   top_cpuset.effective_cpus.  Thus invoking sys_sched_setaffinity() at
>   this moment can cause following:
> 
>Unable to handle kernel NULL pointer dereference at virtual address 
> 00d0
>[ cut here ]
>Kernel BUG at ffc0001389b0 [verbose debug info unavailable]
>Internal error: Oops - BUG: 9605 [#1] PREEMPT SMP
>Modules linked in:
>CPU: 2 PID: 1420 Comm: taskset Tainted: GW   4.4.8+ #98
>task: ffc06a5c4880 ti: ffc06e124000 task.ti: ffc06e124000
>PC is at guarantee_online_cpus+0x2c/0x58
>LR is at cpuset_cpus_allowed+0x4c/0x6c
>
>Process taskset (pid: 1420, stack limit = 0xffc06e124020)
>Call trace:
>[] guarantee_online_cpus+0x2c/0x58
>[] cpuset_cpus_allowed+0x4c/0x6c
>[] sched_setaffinity+0xc0/0x1ac
>[] SyS_sched_setaffinity+0x98/0xac
>[] el0_svc_naked+0x24/0x28
> 
> The top cpuset's effective_cpus are guaranteed to be identical to online
> CPUs eventually.  Hence fall back to online CPU mask when there is no
> intersection between top cpuset's effective_cpus and online CPU mask.
> 
> Signed-off-by: Joonwoo Park 
> Cc: Li Zefan 
> Cc: cgro...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org

Thanks for fixing this!

Acked-by: Zefan Li 
Cc:  # 3.17+

> ---
>  kernel/cpuset.c | 17 ++---
>  1 file changed, 14 insertions(+), 3 deletions(-)
> 
> diff --git a/kernel/cpuset.c b/kernel/cpuset.c
> index c7fd277..b5d2b73 100644
> --- a/kernel/cpuset.c
> +++ b/kernel/cpuset.c
> @@ -325,8 +325,7 @@ static struct file_system_type cpuset_fs_type = {
>  /*
>   * Return in pmask the portion of a cpusets's cpus_allowed that
>   * are online.  If none are online, walk up the cpuset hierarchy
> - * until we find one that does have some online cpus.  The top
> - * cpuset always has some cpus online.
> + * until we find one that does have some online cpus.
>   *
>   * One way or another, we guarantee to return some non-empty subset
>   * of cpu_online_mask.
> @@ -335,8 +334,20 @@ static struct file_system_type cpuset_fs_type = {
>   */
>  static void guarantee_online_cpus(struct cpuset *cs, struct cpumask *pmask)
>  {
> - while (!cpumask_intersects(cs->effective_cpus, cpu_online_mask))
> + while (!cpumask_intersects(cs->effective_cpus, cpu_online_mask)) {
>   cs = parent_cs(cs);
> + if (unlikely(!cs)) {
> + /*
> +  * The top cpuset doesn't have any online cpu in
> +  * consequence of race between cpuset_hotplug_work
> +  * and cpu hotplug notifier.  But we know the top
> +  * cpuset's effective_cpus is on its way to be same
> +  * with online cpus mask.
> +  */
> + cpumask_copy(pmask, cpu_online_mask);
> + return;
> + }
> + }
>   cpumask_and(pmask, cs->effective_cpus, cpu_online_mask);
>  }
>  
> 

Re: [PATCH 25/26] pch_gbe: constify local structures

[David Miller]

Julia, I went over the networking driver patches in this series and
I have to say that I'd rather see these changes be more durable
and self-checking.

By this I mean that I want you to also make the driver private pointer
that holds these structures be const too.

Then if there are really any assignments to the objects being marked
const, it will show immediately.

Thank you.

Re: [PATCH 25/26] pch_gbe: constify local structures

[David Miller]

Julia, I went over the networking driver patches in this series and
I have to say that I'd rather see these changes be more durable
and self-checking.

By this I mean that I want you to also make the driver private pointer
that holds these structures be const too.

Then if there are really any assignments to the objects being marked
const, it will show immediately.

Thank you.

Re: crash by cdc_acm driver in kernels 4.8-rc1/5

[Wim Osterholt]

On Thu, Sep 08, 2016 at 03:05:15PM +0200, Oliver Neukum wrote:
> 
> your stack trace is broken. Did you fail to install the System.map file?
> 
>   Regards
>   Oliver

A laptop, more broken than the rest, does not output anything after
inserting. Later on it crashes. No system.map file in /boot.
After booting with the dongle inserted it spits out:

[   17.204261] fbcon: radeondrmfb (fb0) is primary device
[   17.276234] BUG: unable to handle kernel NULL pointer dereference at 0007
[   17.276266] IP: [] acm_probe+0x450/0xed0 [cdc_acm]
[   17.276272] *pde =  
[   17.276278] Oops:  [#1] PREEMPT SMP
[   17.276362] Modules linked in: cdc_acm(+) radeon(+) fbcon i2c_algo_bit 
bitblit softcursor font drm_kms_helper cfbfillrect syscopyarea cfbimgblt 
sysfillrect sysimgblt fb_sys_fops cfbcopyarea ttm snd_intel8x0m snd_intel8x0 
pcmcia snd_ac97_codec drm dell_smm_hwmon hwmon ipw2200 fb uhci_hcd fbdev 
ehci_pci yenta_socket ehci_hcd ac97_bus snd_pcm dcdbas libipw usbcore 
pcmcia_rsrc pcmcia_core snd_timer lib80211 cfg80211 3c59x snd serio_raw 
intel_agp soundcore usb_common 8250_pci mii video intel_gtt agpgart 8250 
8250_base parport_pc parport serial_core
[   17.276371] CPU: 0 PID: 1311 Comm: udevd Not tainted 4.8.0-rc5 #1
[   17.276375] Hardware name: Dell Computer Corporation Inspiron 4100   
/Inspiron 4100, BIOS A13 05/16/2003
[   17.276379] task: cf9667c0 task.stack: cf10a000
[   17.276385] EIP: 0060:[] EFLAGS: 00010202 CPU: 0
[   17.276400] EIP is at acm_probe+0x450/0xed0 [cdc_acm]
[   17.276404] EAX: 0004 EBX: cbb62800 ECX: 0040 EDX: 0040
[   17.276409] ESI:  EDI:  EBP: cf10bd00 ESP: cf10bc60
[   17.276413]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[   17.276418] CR0: 80050033 CR2: 0007 CR3: 0f07f000 CR4: 06d0
[   17.276420] Stack:
[   17.276435]   0082 0012  46dd cf29ac80 cf9e6238 
cf90cb84
[   17.276448]  cf801c08 0012 45c0 0080 cf9e6200 cf88d960 0010 
cc884470
[   17.276462]  cc884400 0001 cf194a00 cf193000 cf194a00 c14f00ff cc8844f8 
cf9667c0
[   17.276464] Call Trace:
[   17.276486]  [] ? _raw_spin_unlock_irqrestore+0xf/0x30
[   17.276498]  [] ? preempt_count_add+0x89/0x90
[   17.276505]  [] ? preempt_count_add+0x89/0x90
[   17.276512]  [] ? _raw_spin_lock_irqsave+0x11/0x40
[   17.276611]  [] ? usb_probe_interface+0xfc/0x2d0 [usbcore]
[   17.276657]  [] ? usb_probe_interface+0xfc/0x2d0 [usbcore]
[   17.276675]  [] ? driver_probe_device+0x1ff/0x400
[   17.276682]  [] ? driver_probe_device+0x1ff/0x400
[   17.276691]  [] ? __driver_attach+0xd9/0x100
[   17.276698]  [] ? __driver_attach+0xd9/0x100
[   17.276706]  [] ? _raw_spin_lock+0xd/0x30
[   17.276712]  [] ? _raw_spin_unlock+0xd/0x30
[   17.276720]  [] ? driver_probe_device+0x400/0x400
[   17.276728]  [] ? bus_for_each_dev+0x47/0x80
[   17.276735]  [] ? bus_for_each_dev+0x47/0x80
[   17.276743]  [] ? driver_attach+0x11/0x20
[   17.276750]  [] ? driver_probe_device+0x400/0x400
[   17.276757]  [] ? bus_add_driver+0x1df/0x270
[   17.276764]  [] ? _raw_spin_unlock+0xd/0x30
[   17.276777]  [] ? kset_find_obj+0x44/0x90
[   17.276785]  [] ? driver_register+0x4e/0xc0
[   17.276791]  [] ? driver_register+0x4e/0xc0
[   17.276837]  [] ? usb_register_driver+0x5a/0x110 [usbcore]
[   17.276852]  [] ? acm_init+0xa7/0xd6 [cdc_acm]
[   17.276857]  [] ? 0xd07f9000
[   17.276864]  [] ? do_one_initcall+0x2d/0x130
[   17.276880]  [] ? do_init_module+0x19/0x1a0
[   17.276889]  [] ? do_init_module+0x48/0x1a0
[   17.276900]  [] ? load_module+0x19c7/0x2150
[   17.276913]  [] ? kernel_read_file+0x103/0x200
[   17.276922]  [] ? SyS_finit_module+0x90/0xd0
[   17.276929]  [] ? SyS_finit_module+0x90/0xd0
[   17.276940]  [] ? do_int80_syscall_32+0x38/0x90
[   17.276946]  [] ? do_int80_syscall_32+0x38/0x90
[   17.276954]  [] ? entry_INT80_32+0x2a/0x2a
[   17.277046] Code: 04 89 b3 c0 04 00 00 8d 04 80 c1 e0 02 89 83 b4 04 00 00 
8b 45 a8 89 43 04 8b 45 ac 89 43 08 8b 45 a0 89 03 8b 45 c0 85 c0 74 0a <0f> b6 
40 03 89 83 c8 04 00 00 f6 45 a4 04 74 07 83 a3 c8 04 00
[   17.277065] EIP: [] acm_probe+0x450/0xed0 [cdc_acm] SS:ESP 
0068:cf10bc60
[   17.277068] CR2: 0007
[   17.277360] ---[ end trace 5847748dfb454f14 ]---
[   17.280317] udevd[1295]: worker [1311] terminated by signal 9 (Killed)
[   17.280333] udevd[1295]: worker [1311] failed while handling 
'/devices/pci:00/:00:1d.0/usb1/1-1/1-1:1.0'

Re: crash by cdc_acm driver in kernels 4.8-rc1/5

[Wim Osterholt]

On Thu, Sep 08, 2016 at 03:05:15PM +0200, Oliver Neukum wrote:
> 
> your stack trace is broken. Did you fail to install the System.map file?
> 
>   Regards
>   Oliver

A laptop, more broken than the rest, does not output anything after
inserting. Later on it crashes. No system.map file in /boot.
After booting with the dongle inserted it spits out:

[   17.204261] fbcon: radeondrmfb (fb0) is primary device
[   17.276234] BUG: unable to handle kernel NULL pointer dereference at 0007
[   17.276266] IP: [] acm_probe+0x450/0xed0 [cdc_acm]
[   17.276272] *pde =  
[   17.276278] Oops:  [#1] PREEMPT SMP
[   17.276362] Modules linked in: cdc_acm(+) radeon(+) fbcon i2c_algo_bit 
bitblit softcursor font drm_kms_helper cfbfillrect syscopyarea cfbimgblt 
sysfillrect sysimgblt fb_sys_fops cfbcopyarea ttm snd_intel8x0m snd_intel8x0 
pcmcia snd_ac97_codec drm dell_smm_hwmon hwmon ipw2200 fb uhci_hcd fbdev 
ehci_pci yenta_socket ehci_hcd ac97_bus snd_pcm dcdbas libipw usbcore 
pcmcia_rsrc pcmcia_core snd_timer lib80211 cfg80211 3c59x snd serio_raw 
intel_agp soundcore usb_common 8250_pci mii video intel_gtt agpgart 8250 
8250_base parport_pc parport serial_core
[   17.276371] CPU: 0 PID: 1311 Comm: udevd Not tainted 4.8.0-rc5 #1
[   17.276375] Hardware name: Dell Computer Corporation Inspiron 4100   
/Inspiron 4100, BIOS A13 05/16/2003
[   17.276379] task: cf9667c0 task.stack: cf10a000
[   17.276385] EIP: 0060:[] EFLAGS: 00010202 CPU: 0
[   17.276400] EIP is at acm_probe+0x450/0xed0 [cdc_acm]
[   17.276404] EAX: 0004 EBX: cbb62800 ECX: 0040 EDX: 0040
[   17.276409] ESI:  EDI:  EBP: cf10bd00 ESP: cf10bc60
[   17.276413]  DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
[   17.276418] CR0: 80050033 CR2: 0007 CR3: 0f07f000 CR4: 06d0
[   17.276420] Stack:
[   17.276435]   0082 0012  46dd cf29ac80 cf9e6238 
cf90cb84
[   17.276448]  cf801c08 0012 45c0 0080 cf9e6200 cf88d960 0010 
cc884470
[   17.276462]  cc884400 0001 cf194a00 cf193000 cf194a00 c14f00ff cc8844f8 
cf9667c0
[   17.276464] Call Trace:
[   17.276486]  [] ? _raw_spin_unlock_irqrestore+0xf/0x30
[   17.276498]  [] ? preempt_count_add+0x89/0x90
[   17.276505]  [] ? preempt_count_add+0x89/0x90
[   17.276512]  [] ? _raw_spin_lock_irqsave+0x11/0x40
[   17.276611]  [] ? usb_probe_interface+0xfc/0x2d0 [usbcore]
[   17.276657]  [] ? usb_probe_interface+0xfc/0x2d0 [usbcore]
[   17.276675]  [] ? driver_probe_device+0x1ff/0x400
[   17.276682]  [] ? driver_probe_device+0x1ff/0x400
[   17.276691]  [] ? __driver_attach+0xd9/0x100
[   17.276698]  [] ? __driver_attach+0xd9/0x100
[   17.276706]  [] ? _raw_spin_lock+0xd/0x30
[   17.276712]  [] ? _raw_spin_unlock+0xd/0x30
[   17.276720]  [] ? driver_probe_device+0x400/0x400
[   17.276728]  [] ? bus_for_each_dev+0x47/0x80
[   17.276735]  [] ? bus_for_each_dev+0x47/0x80
[   17.276743]  [] ? driver_attach+0x11/0x20
[   17.276750]  [] ? driver_probe_device+0x400/0x400
[   17.276757]  [] ? bus_add_driver+0x1df/0x270
[   17.276764]  [] ? _raw_spin_unlock+0xd/0x30
[   17.276777]  [] ? kset_find_obj+0x44/0x90
[   17.276785]  [] ? driver_register+0x4e/0xc0
[   17.276791]  [] ? driver_register+0x4e/0xc0
[   17.276837]  [] ? usb_register_driver+0x5a/0x110 [usbcore]
[   17.276852]  [] ? acm_init+0xa7/0xd6 [cdc_acm]
[   17.276857]  [] ? 0xd07f9000
[   17.276864]  [] ? do_one_initcall+0x2d/0x130
[   17.276880]  [] ? do_init_module+0x19/0x1a0
[   17.276889]  [] ? do_init_module+0x48/0x1a0
[   17.276900]  [] ? load_module+0x19c7/0x2150
[   17.276913]  [] ? kernel_read_file+0x103/0x200
[   17.276922]  [] ? SyS_finit_module+0x90/0xd0
[   17.276929]  [] ? SyS_finit_module+0x90/0xd0
[   17.276940]  [] ? do_int80_syscall_32+0x38/0x90
[   17.276946]  [] ? do_int80_syscall_32+0x38/0x90
[   17.276954]  [] ? entry_INT80_32+0x2a/0x2a
[   17.277046] Code: 04 89 b3 c0 04 00 00 8d 04 80 c1 e0 02 89 83 b4 04 00 00 
8b 45 a8 89 43 04 8b 45 ac 89 43 08 8b 45 a0 89 03 8b 45 c0 85 c0 74 0a <0f> b6 
40 03 89 83 c8 04 00 00 f6 45 a4 04 74 07 83 a3 c8 04 00
[   17.277065] EIP: [] acm_probe+0x450/0xed0 [cdc_acm] SS:ESP 
0068:cf10bc60
[   17.277068] CR2: 0007
[   17.277360] ---[ end trace 5847748dfb454f14 ]---
[   17.280317] udevd[1295]: worker [1311] terminated by signal 9 (Killed)
[   17.280333] udevd[1295]: worker [1311] failed while handling 
'/devices/pci:00/:00:1d.0/usb1/1-1/1-1:1.0'

Re: [PATCH] extcon: Introduce EXTCON_PROP_DISP_HPD property

[Chanwoo Choi]

Hi Guenter,

On 2016년 09월 12일 11:29, Guenter Roeck wrote:
> On Sun, Sep 11, 2016 at 7:23 PM, Chanwoo Choi  wrote:
>> Hi Chris,
>>
>> On 2016년 09월 12일 10:03, Chanwoo Choi wrote:
>>> Hi Chris,
>>>
>>> On 2016년 09월 10일 09:33, Chris Zhong wrote:
 EXTCON_PROP_DISP_HPD is need by display port, if the system has no hpd
 interrupt, this property can be used.
>>>
>>> What is meaning of HPD? So, you need to add the
>>> description and reference for HPD in commit message.
>>>
>>> For example,
>>> When adding EXTCON_PROP_USB_SS property[1],
>>> the commit message included the reference for USB SuperSpeed.
>>> [1] 
>>> https://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/commit/?h=extcon-next=8457a1b49a2af0a0e71f80afed9f7c80de361610
>>>

 Change-Id: I8b3eb78429126eaa369b10711b7f857b0a3df8ed
>>>
>>> You have to remove the 'Change-Id'.
>>>
 Signed-off-by: Chris Zhong 
 ---
  include/linux/extcon.h | 14 +-
  1 file changed, 13 insertions(+), 1 deletion(-)

 diff --git a/include/linux/extcon.h b/include/linux/extcon.h
 index 9147c42..4411893 100644
 --- a/include/linux/extcon.h
 +++ b/include/linux/extcon.h
 @@ -131,9 +131,21 @@
  #define EXTCON_PROP_JACK_MAX100
  #define EXTCON_PROP_JACK_CNT (EXTCON_PROP_JACK_MAX - EXTCON_PROP_JACK_MIN 
 + 1)

 +/*
 + * Properties of EXTCON_TYPE_DISP.
 + *
 + * - EXTCON_PROP_DISP_HPD
>>>
>>> You should add the full name of 'HPD'.
>>
>> On previous mail, I replied ambiguous comment.
>>
>> I mean that you better to add the property name with full name as following:
>>
>> EXTCON_PROP_DISP_HPD ( Hxxx Pxxx Dxxx)
> 
> What do you prefer ?
> 
> HOTPLUGDETECT ? HOT_PLUG_DETECT ? HOTPLUG_DETECT ?

I prefer to add 'HPD (Hot Plug Detect)'.

> 
> The term "HPD" seems to be quite common in the DisplayPort world; in
> most presentations it isn't even explained. Personally I would prefer
> to stick with HPD and explain it in the comments.

People who are unfamiliar with DisplayPort world
need the explanation and full name of HPD. 
Basically, all abbreviation should show the full name.

-- 
Best Regards,
Chanwoo Choi

Re: [PATCH] extcon: Introduce EXTCON_PROP_DISP_HPD property

[Chanwoo Choi]

Hi Guenter,

On 2016년 09월 12일 11:29, Guenter Roeck wrote:
> On Sun, Sep 11, 2016 at 7:23 PM, Chanwoo Choi  wrote:
>> Hi Chris,
>>
>> On 2016년 09월 12일 10:03, Chanwoo Choi wrote:
>>> Hi Chris,
>>>
>>> On 2016년 09월 10일 09:33, Chris Zhong wrote:
 EXTCON_PROP_DISP_HPD is need by display port, if the system has no hpd
 interrupt, this property can be used.
>>>
>>> What is meaning of HPD? So, you need to add the
>>> description and reference for HPD in commit message.
>>>
>>> For example,
>>> When adding EXTCON_PROP_USB_SS property[1],
>>> the commit message included the reference for USB SuperSpeed.
>>> [1] 
>>> https://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/commit/?h=extcon-next=8457a1b49a2af0a0e71f80afed9f7c80de361610
>>>

 Change-Id: I8b3eb78429126eaa369b10711b7f857b0a3df8ed
>>>
>>> You have to remove the 'Change-Id'.
>>>
 Signed-off-by: Chris Zhong 
 ---
  include/linux/extcon.h | 14 +-
  1 file changed, 13 insertions(+), 1 deletion(-)

 diff --git a/include/linux/extcon.h b/include/linux/extcon.h
 index 9147c42..4411893 100644
 --- a/include/linux/extcon.h
 +++ b/include/linux/extcon.h
 @@ -131,9 +131,21 @@
  #define EXTCON_PROP_JACK_MAX100
  #define EXTCON_PROP_JACK_CNT (EXTCON_PROP_JACK_MAX - EXTCON_PROP_JACK_MIN 
 + 1)

 +/*
 + * Properties of EXTCON_TYPE_DISP.
 + *
 + * - EXTCON_PROP_DISP_HPD
>>>
>>> You should add the full name of 'HPD'.
>>
>> On previous mail, I replied ambiguous comment.
>>
>> I mean that you better to add the property name with full name as following:
>>
>> EXTCON_PROP_DISP_HPD ( Hxxx Pxxx Dxxx)
> 
> What do you prefer ?
> 
> HOTPLUGDETECT ? HOT_PLUG_DETECT ? HOTPLUG_DETECT ?

I prefer to add 'HPD (Hot Plug Detect)'.

> 
> The term "HPD" seems to be quite common in the DisplayPort world; in
> most presentations it isn't even explained. Personally I would prefer
> to stick with HPD and explain it in the comments.

People who are unfamiliar with DisplayPort world
need the explanation and full name of HPD. 
Basically, all abbreviation should show the full name.

-- 
Best Regards,
Chanwoo Choi

Re: [PATCH] MAINTAINERS: Add MFD's DT bindings directory to MFD entry

[Andrew Jeffery]

On Thu, 2016-09-08 at 09:07 +0100, Lee Jones wrote:
> Signed-off-by: Lee Jones 

Reviewed-by: Andrew Jeffery 

> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a306795..022da8c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7945,6 +7945,7 @@ MULTIFUNCTION DEVICES (MFD)
>  M:   Lee Jones 
>  T:   git
> git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git
>  S:   Supported
> +F:   Documentation/devicetree/bindings/mfd/
>  F:   drivers/mfd/
>  F:   include/linux/mfd/
>  

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

Re: [PATCH] MAINTAINERS: Add MFD's DT bindings directory to MFD entry

[Andrew Jeffery]

On Thu, 2016-09-08 at 09:07 +0100, Lee Jones wrote:
> Signed-off-by: Lee Jones 

Reviewed-by: Andrew Jeffery 

> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index a306795..022da8c 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7945,6 +7945,7 @@ MULTIFUNCTION DEVICES (MFD)
>  M:   Lee Jones 
>  T:   git
> git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git
>  S:   Supported
> +F:   Documentation/devicetree/bindings/mfd/
>  F:   drivers/mfd/
>  F:   include/linux/mfd/
>  

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

Re: Question on smp_mb__before_spinlock

[Nicholas Piggin]

On Wed, 7 Sep 2016 14:51:47 +0100
Will Deacon  wrote:

> On Wed, Sep 07, 2016 at 03:23:54PM +0200, Peter Zijlstra wrote:
> > On Wed, Sep 07, 2016 at 10:17:26PM +1000, Nicholas Piggin wrote:  
> > > It seems okay, but why not make it a special sched-only function name
> > > to prevent it being used in generic code?
> > > 
> > > I would not mind seeing responsibility for the switch barrier moved to
> > > generic context switch code like this (alternative for powerpc reducing
> > > number of hwsync instructions was to add documentation and warnings about
> > > the barriers in arch dependent and independent code). And pairing it with
> > > a spinlock is reasonable.
> > > 
> > > It may not strictly be an "smp_" style of barrier if MMIO accesses are to
> > > be ordered here too, despite critical section may only be providing
> > > acquire/release for cacheable memory, so maybe it's slightly more
> > > complicated than just cacheable RCsc?  
> > 
> > Interesting idea..
> > 
> > So I'm not a fan of that raw_spin_lock wrapper, since that would end up
> > with a lot more boiler-plate code than just the one extra barrier.
> > 
> > But moving MMIO/DMA/TLB etc.. barriers into this spinlock might not be a
> > good idea, since those are typically fairly heavy barriers, and its
> > quite common to call schedule() without ending up in switch_to().
> > 
> > For PowerPC it works out, since there's only SYNC, no other option
> > afaik.
> > 
> > But ARM/ARM64 will have to do DSB(ISH) instead of DMB(ISH). IA64 would
> > need to issue "sync.i" and mips-octeon "synciobdma".
> > 
> > Will, any idea of the extra cost involved in DSB vs DMB?  
> 
> DSB is *much* more expensive, since it completes out-of-band communication
> such as MMIO accesses and TLB invalidation, as well as plain old memory
> accesses.
> 
> The only reason we have DSB in our __switch_to code is to complete cache
> maintenance in case the task is going to migrate to another CPU; there's
> just no way to know that at the point we need to do the barrier :(

Unfortunately it's not trivial to move such barriers to migrate-time,
because the source CPU may not be involved after the task is switched
out.

This won't prevent ARM32/64 from continuing to do what it does today,
if we note that the arch must provide such barriers *either* in the
context switch lock / barrier, or in its own switch code.

Thanks,
Nick

Re: Question on smp_mb__before_spinlock

[Nicholas Piggin]

On Wed, 7 Sep 2016 14:51:47 +0100
Will Deacon  wrote:

> On Wed, Sep 07, 2016 at 03:23:54PM +0200, Peter Zijlstra wrote:
> > On Wed, Sep 07, 2016 at 10:17:26PM +1000, Nicholas Piggin wrote:  
> > > It seems okay, but why not make it a special sched-only function name
> > > to prevent it being used in generic code?
> > > 
> > > I would not mind seeing responsibility for the switch barrier moved to
> > > generic context switch code like this (alternative for powerpc reducing
> > > number of hwsync instructions was to add documentation and warnings about
> > > the barriers in arch dependent and independent code). And pairing it with
> > > a spinlock is reasonable.
> > > 
> > > It may not strictly be an "smp_" style of barrier if MMIO accesses are to
> > > be ordered here too, despite critical section may only be providing
> > > acquire/release for cacheable memory, so maybe it's slightly more
> > > complicated than just cacheable RCsc?  
> > 
> > Interesting idea..
> > 
> > So I'm not a fan of that raw_spin_lock wrapper, since that would end up
> > with a lot more boiler-plate code than just the one extra barrier.
> > 
> > But moving MMIO/DMA/TLB etc.. barriers into this spinlock might not be a
> > good idea, since those are typically fairly heavy barriers, and its
> > quite common to call schedule() without ending up in switch_to().
> > 
> > For PowerPC it works out, since there's only SYNC, no other option
> > afaik.
> > 
> > But ARM/ARM64 will have to do DSB(ISH) instead of DMB(ISH). IA64 would
> > need to issue "sync.i" and mips-octeon "synciobdma".
> > 
> > Will, any idea of the extra cost involved in DSB vs DMB?  
> 
> DSB is *much* more expensive, since it completes out-of-band communication
> such as MMIO accesses and TLB invalidation, as well as plain old memory
> accesses.
> 
> The only reason we have DSB in our __switch_to code is to complete cache
> maintenance in case the task is going to migrate to another CPU; there's
> just no way to know that at the point we need to do the barrier :(

Unfortunately it's not trivial to move such barriers to migrate-time,
because the source CPU may not be involved after the task is switched
out.

This won't prevent ARM32/64 from continuing to do what it does today,
if we note that the arch must provide such barriers *either* in the
context switch lock / barrier, or in its own switch code.

Thanks,
Nick

Re: [PATCH] extcon: Introduce EXTCON_PROP_DISP_HPD property

[Guenter Roeck]

On Sun, Sep 11, 2016 at 7:23 PM, Chanwoo Choi  wrote:
> Hi Chris,
>
> On 2016년 09월 12일 10:03, Chanwoo Choi wrote:
>> Hi Chris,
>>
>> On 2016년 09월 10일 09:33, Chris Zhong wrote:
>>> EXTCON_PROP_DISP_HPD is need by display port, if the system has no hpd
>>> interrupt, this property can be used.
>>
>> What is meaning of HPD? So, you need to add the
>> description and reference for HPD in commit message.
>>
>> For example,
>> When adding EXTCON_PROP_USB_SS property[1],
>> the commit message included the reference for USB SuperSpeed.
>> [1] 
>> https://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/commit/?h=extcon-next=8457a1b49a2af0a0e71f80afed9f7c80de361610
>>
>>>
>>> Change-Id: I8b3eb78429126eaa369b10711b7f857b0a3df8ed
>>
>> You have to remove the 'Change-Id'.
>>
>>> Signed-off-by: Chris Zhong 
>>> ---
>>>  include/linux/extcon.h | 14 +-
>>>  1 file changed, 13 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/include/linux/extcon.h b/include/linux/extcon.h
>>> index 9147c42..4411893 100644
>>> --- a/include/linux/extcon.h
>>> +++ b/include/linux/extcon.h
>>> @@ -131,9 +131,21 @@
>>>  #define EXTCON_PROP_JACK_MAX100
>>>  #define EXTCON_PROP_JACK_CNT (EXTCON_PROP_JACK_MAX - EXTCON_PROP_JACK_MIN 
>>> + 1)
>>>
>>> +/*
>>> + * Properties of EXTCON_TYPE_DISP.
>>> + *
>>> + * - EXTCON_PROP_DISP_HPD
>>
>> You should add the full name of 'HPD'.
>
> On previous mail, I replied ambiguous comment.
>
> I mean that you better to add the property name with full name as following:
>
> EXTCON_PROP_DISP_HPD ( Hxxx Pxxx Dxxx)

What do you prefer ?

HOTPLUGDETECT ? HOT_PLUG_DETECT ? HOTPLUG_DETECT ?

The term "HPD" seems to be quite common in the DisplayPort world; in
most presentations it isn't even explained. Personally I would prefer
to stick with HPD and explain it in the comments.

Guenter

>
> [snip]
>
> --
> Best Regards,
> Chanwoo Choi

Re: [PATCH] extcon: Introduce EXTCON_PROP_DISP_HPD property

[Guenter Roeck]

On Sun, Sep 11, 2016 at 7:23 PM, Chanwoo Choi  wrote:
> Hi Chris,
>
> On 2016년 09월 12일 10:03, Chanwoo Choi wrote:
>> Hi Chris,
>>
>> On 2016년 09월 10일 09:33, Chris Zhong wrote:
>>> EXTCON_PROP_DISP_HPD is need by display port, if the system has no hpd
>>> interrupt, this property can be used.
>>
>> What is meaning of HPD? So, you need to add the
>> description and reference for HPD in commit message.
>>
>> For example,
>> When adding EXTCON_PROP_USB_SS property[1],
>> the commit message included the reference for USB SuperSpeed.
>> [1] 
>> https://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/commit/?h=extcon-next=8457a1b49a2af0a0e71f80afed9f7c80de361610
>>
>>>
>>> Change-Id: I8b3eb78429126eaa369b10711b7f857b0a3df8ed
>>
>> You have to remove the 'Change-Id'.
>>
>>> Signed-off-by: Chris Zhong 
>>> ---
>>>  include/linux/extcon.h | 14 +-
>>>  1 file changed, 13 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/include/linux/extcon.h b/include/linux/extcon.h
>>> index 9147c42..4411893 100644
>>> --- a/include/linux/extcon.h
>>> +++ b/include/linux/extcon.h
>>> @@ -131,9 +131,21 @@
>>>  #define EXTCON_PROP_JACK_MAX100
>>>  #define EXTCON_PROP_JACK_CNT (EXTCON_PROP_JACK_MAX - EXTCON_PROP_JACK_MIN 
>>> + 1)
>>>
>>> +/*
>>> + * Properties of EXTCON_TYPE_DISP.
>>> + *
>>> + * - EXTCON_PROP_DISP_HPD
>>
>> You should add the full name of 'HPD'.
>
> On previous mail, I replied ambiguous comment.
>
> I mean that you better to add the property name with full name as following:
>
> EXTCON_PROP_DISP_HPD ( Hxxx Pxxx Dxxx)

What do you prefer ?

HOTPLUGDETECT ? HOT_PLUG_DETECT ? HOTPLUG_DETECT ?

The term "HPD" seems to be quite common in the DisplayPort world; in
most presentations it isn't even explained. Personally I would prefer
to stick with HPD and explain it in the comments.

Guenter

>
> [snip]
>
> --
> Best Regards,
> Chanwoo Choi

Re: Question on smp_mb__before_spinlock

[Nicholas Piggin]

On Wed, 7 Sep 2016 15:23:54 +0200
Peter Zijlstra  wrote:

> On Wed, Sep 07, 2016 at 10:17:26PM +1000, Nicholas Piggin wrote:
> > >  /*
> > > + * This barrier must provide two things:
> > > + *
> > > + *   - it must guarantee a STORE before the spin_lock() is ordered 
> > > against a
> > > + * LOAD after it, see the comments at its two usage sites.
> > > + *
> > > + *   - it must ensure the critical section is RCsc.
> > > + *
> > > + * The latter is important for cases where we observe values written by 
> > > other
> > > + * CPUs in spin-loops, without barriers, while being subject to 
> > > scheduling.
> > > + *
> > > + * CPU0  CPU1CPU2
> > > + * 
> > > + *   for (;;) {
> > > + * if (READ_ONCE(X))
> > > + *   break;
> > > + *   }
> > > + * X=1
> > > + *   
> > > + *   
> > > + *   r = X;
> > > + *
> > > + * without transitivity it could be that CPU1 observes X!=0 breaks the 
> > > loop,
> > > + * we get migrated and CPU2 sees X==0.
> > > + *
> > > + * Since most load-store architectures implement ACQUIRE with an 
> > > smp_mb() after
> > > + * the LL/SC loop, they need no further barriers. Similarly all our TSO
> > > + * architectures imlpy an smp_mb() for each atomic instruction and 
> > > equally don't
> > > + * need more.
> > > + *
> > > + * Architectures that can implement ACQUIRE better need to take care.
> > >   */
> > > +#ifndef smp_mb__after_spinlock
> > > +#define smp_mb__after_spinlock() do { } while (0)
> > >  #endif  
> > 
> > It seems okay, but why not make it a special sched-only function name
> > to prevent it being used in generic code?
> > 
> > I would not mind seeing responsibility for the switch barrier moved to
> > generic context switch code like this (alternative for powerpc reducing
> > number of hwsync instructions was to add documentation and warnings about
> > the barriers in arch dependent and independent code). And pairing it with
> > a spinlock is reasonable.
> > 
> > It may not strictly be an "smp_" style of barrier if MMIO accesses are to
> > be ordered here too, despite critical section may only be providing
> > acquire/release for cacheable memory, so maybe it's slightly more
> > complicated than just cacheable RCsc?  
> 
> Interesting idea..
> 
> So I'm not a fan of that raw_spin_lock wrapper, since that would end up
> with a lot more boiler-plate code than just the one extra barrier.

#ifndef sched_ctxsw_raw_spin_lock
#define sched_ctxsw_raw_spin_lock(lock) raw_spin_lock(lock)
#endif

#define sched_ctxsw_raw_spin_lock(lock) do { smp_mb() ; raw_spin_lock(lock); } 
while (0)

?


> But moving MMIO/DMA/TLB etc.. barriers into this spinlock might not be a
> good idea, since those are typically fairly heavy barriers, and its
> quite common to call schedule() without ending up in switch_to().

That's true I guess, but if we already have the arch specific smp_mb__
specifically for this context switch code, and you are asking for them to
implement *cacheable* memory barrier vs migration, then I see no reason
not to allow them to implement uncacheable as well.

You make a good point about schedule() without switch_to(), but
architectures will still have no less flexibility than they do now.

Thanks,
Nick

Re: Question on smp_mb__before_spinlock

[Nicholas Piggin]

On Wed, 7 Sep 2016 15:23:54 +0200
Peter Zijlstra  wrote:

> On Wed, Sep 07, 2016 at 10:17:26PM +1000, Nicholas Piggin wrote:
> > >  /*
> > > + * This barrier must provide two things:
> > > + *
> > > + *   - it must guarantee a STORE before the spin_lock() is ordered 
> > > against a
> > > + * LOAD after it, see the comments at its two usage sites.
> > > + *
> > > + *   - it must ensure the critical section is RCsc.
> > > + *
> > > + * The latter is important for cases where we observe values written by 
> > > other
> > > + * CPUs in spin-loops, without barriers, while being subject to 
> > > scheduling.
> > > + *
> > > + * CPU0  CPU1CPU2
> > > + * 
> > > + *   for (;;) {
> > > + * if (READ_ONCE(X))
> > > + *   break;
> > > + *   }
> > > + * X=1
> > > + *   
> > > + *   
> > > + *   r = X;
> > > + *
> > > + * without transitivity it could be that CPU1 observes X!=0 breaks the 
> > > loop,
> > > + * we get migrated and CPU2 sees X==0.
> > > + *
> > > + * Since most load-store architectures implement ACQUIRE with an 
> > > smp_mb() after
> > > + * the LL/SC loop, they need no further barriers. Similarly all our TSO
> > > + * architectures imlpy an smp_mb() for each atomic instruction and 
> > > equally don't
> > > + * need more.
> > > + *
> > > + * Architectures that can implement ACQUIRE better need to take care.
> > >   */
> > > +#ifndef smp_mb__after_spinlock
> > > +#define smp_mb__after_spinlock() do { } while (0)
> > >  #endif  
> > 
> > It seems okay, but why not make it a special sched-only function name
> > to prevent it being used in generic code?
> > 
> > I would not mind seeing responsibility for the switch barrier moved to
> > generic context switch code like this (alternative for powerpc reducing
> > number of hwsync instructions was to add documentation and warnings about
> > the barriers in arch dependent and independent code). And pairing it with
> > a spinlock is reasonable.
> > 
> > It may not strictly be an "smp_" style of barrier if MMIO accesses are to
> > be ordered here too, despite critical section may only be providing
> > acquire/release for cacheable memory, so maybe it's slightly more
> > complicated than just cacheable RCsc?  
> 
> Interesting idea..
> 
> So I'm not a fan of that raw_spin_lock wrapper, since that would end up
> with a lot more boiler-plate code than just the one extra barrier.

#ifndef sched_ctxsw_raw_spin_lock
#define sched_ctxsw_raw_spin_lock(lock) raw_spin_lock(lock)
#endif

#define sched_ctxsw_raw_spin_lock(lock) do { smp_mb() ; raw_spin_lock(lock); } 
while (0)

?


> But moving MMIO/DMA/TLB etc.. barriers into this spinlock might not be a
> good idea, since those are typically fairly heavy barriers, and its
> quite common to call schedule() without ending up in switch_to().

That's true I guess, but if we already have the arch specific smp_mb__
specifically for this context switch code, and you are asking for them to
implement *cacheable* memory barrier vs migration, then I see no reason
not to allow them to implement uncacheable as well.

You make a good point about schedule() without switch_to(), but
architectures will still have no less flexibility than they do now.

Thanks,
Nick

Re: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)

[Guenter Roeck]

On Sun, Sep 11, 2016 at 7:16 PM, Jun Li  wrote:
> Hi Guenter
>
>> -Original Message-
>> From: Guenter Roeck [mailto:gro...@google.com]
>> Sent: Saturday, September 10, 2016 10:23 AM
>> To: Jun Li 
>> Cc: Guenter Roeck ; Felipe Balbi
>> ; Chandra Sekhar Anagani
>> ; Bruce Ashfield
>> ; Bin Gao ; Pranav Tipnis
>> ; Heikki Krogerus
>> ; linux-kernel@vger.kernel.org; linux-
>> u...@vger.kernel.org
>> Subject: Re: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)
>>
>> On Fri, Sep 9, 2016 at 5:26 PM, Jun Li  wrote:
>> > Hi Guenter,
>> >
>> >> -Original Message-
>> >> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
>> >> ow...@vger.kernel.org] On Behalf Of Guenter Roeck
>> >> Sent: Wednesday, August 24, 2016 5:11 AM
>> >> To: Felipe Balbi 
>> >> Cc: Chandra Sekhar Anagani ; Bruce
>> >> Ashfield ; Bin Gao ;
>> >> Pranav Tipnis ; Heikki Krogerus
>> >> ; linux-kernel@vger.kernel.org;
>> >> linux- u...@vger.kernel.org; Guenter Roeck 
>> >> Subject: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager
>> >> (tcpm)
>> >>
>> >> This driver implements the USB Type-C Power Delivery state machine
>> >> for both source and sink ports. Alternate mode support is not fully
>> >> implemented.
>> >>
>> >> The driver attaches to the USB Type-C class code implemented in the
>> >> following patches.
>> >>
>> >>   usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY
>> >>   usb: USB Type-C connector class
>> >>
>> >> This driver only implements the state machine. Lower level drivers
>> >> are responsible for
>> >> - Reporting VBUS status and activating VBUS
>> >> - Setting CC lines and providing CC line status
>> >> - Setting line polarity
>> >> - Activating and deactivating VCONN
>> >> - Setting the current limit
>> >> - Activating and deactivating PD message transfers
>> >> - Sending and receiving PD messages
>> >>
>> >> The driver provides both a functional API as well as callbacks for
>> >> lower level drivers.
>> >>
>> >> Signed-off-by: Guenter Roeck 
>> >> ---
>> >
>> > A specific question, if power sink wants to request a new power level
>> > after SNK_READY, how to handle it with this tcpm?
>> >
>>
>> So far I have considered the required power level to be static, based on
>> our curent implementations. That should be easy to change, though, with an
>> additional API function, to be called from a low level driver.
>> Do you have that requirement, and would such a function meet your needs ?
>>
>
> So you are going to make port->tcpc->config to be dynamic to meet my need?
>
What would that help ? How would tcpm get informed that the power
requirements changed without an API function telling it that power
requirements changed ?

Guenter

Re: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)

[Guenter Roeck]

On Sun, Sep 11, 2016 at 7:16 PM, Jun Li  wrote:
> Hi Guenter
>
>> -Original Message-
>> From: Guenter Roeck [mailto:gro...@google.com]
>> Sent: Saturday, September 10, 2016 10:23 AM
>> To: Jun Li 
>> Cc: Guenter Roeck ; Felipe Balbi
>> ; Chandra Sekhar Anagani
>> ; Bruce Ashfield
>> ; Bin Gao ; Pranav Tipnis
>> ; Heikki Krogerus
>> ; linux-kernel@vger.kernel.org; linux-
>> u...@vger.kernel.org
>> Subject: Re: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager (tcpm)
>>
>> On Fri, Sep 9, 2016 at 5:26 PM, Jun Li  wrote:
>> > Hi Guenter,
>> >
>> >> -Original Message-
>> >> From: linux-usb-ow...@vger.kernel.org [mailto:linux-usb-
>> >> ow...@vger.kernel.org] On Behalf Of Guenter Roeck
>> >> Sent: Wednesday, August 24, 2016 5:11 AM
>> >> To: Felipe Balbi 
>> >> Cc: Chandra Sekhar Anagani ; Bruce
>> >> Ashfield ; Bin Gao ;
>> >> Pranav Tipnis ; Heikki Krogerus
>> >> ; linux-kernel@vger.kernel.org;
>> >> linux- u...@vger.kernel.org; Guenter Roeck 
>> >> Subject: [RFC PATCH v3 1/2] usb: typec: USB Type-C Port Manager
>> >> (tcpm)
>> >>
>> >> This driver implements the USB Type-C Power Delivery state machine
>> >> for both source and sink ports. Alternate mode support is not fully
>> >> implemented.
>> >>
>> >> The driver attaches to the USB Type-C class code implemented in the
>> >> following patches.
>> >>
>> >>   usb: typec: add driver for Intel Whiskey Cove PMIC USB Type-C PHY
>> >>   usb: USB Type-C connector class
>> >>
>> >> This driver only implements the state machine. Lower level drivers
>> >> are responsible for
>> >> - Reporting VBUS status and activating VBUS
>> >> - Setting CC lines and providing CC line status
>> >> - Setting line polarity
>> >> - Activating and deactivating VCONN
>> >> - Setting the current limit
>> >> - Activating and deactivating PD message transfers
>> >> - Sending and receiving PD messages
>> >>
>> >> The driver provides both a functional API as well as callbacks for
>> >> lower level drivers.
>> >>
>> >> Signed-off-by: Guenter Roeck 
>> >> ---
>> >
>> > A specific question, if power sink wants to request a new power level
>> > after SNK_READY, how to handle it with this tcpm?
>> >
>>
>> So far I have considered the required power level to be static, based on
>> our curent implementations. That should be easy to change, though, with an
>> additional API function, to be called from a low level driver.
>> Do you have that requirement, and would such a function meet your needs ?
>>
>
> So you are going to make port->tcpc->config to be dynamic to meet my need?
>
What would that help ? How would tcpm get informed that the power
requirements changed without an API function telling it that power
requirements changed ?

Guenter

Re: [PATCH] extcon: Introduce EXTCON_PROP_DISP_HPD property

[Chanwoo Choi]

Hi Chris,

On 2016년 09월 12일 10:03, Chanwoo Choi wrote:
> Hi Chris,
> 
> On 2016년 09월 10일 09:33, Chris Zhong wrote:
>> EXTCON_PROP_DISP_HPD is need by display port, if the system has no hpd
>> interrupt, this property can be used.
> 
> What is meaning of HPD? So, you need to add the
> description and reference for HPD in commit message.
> 
> For example,
> When adding EXTCON_PROP_USB_SS property[1],
> the commit message included the reference for USB SuperSpeed.
> [1] 
> https://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/commit/?h=extcon-next=8457a1b49a2af0a0e71f80afed9f7c80de361610
> 
>>
>> Change-Id: I8b3eb78429126eaa369b10711b7f857b0a3df8ed
> 
> You have to remove the 'Change-Id'.
> 
>> Signed-off-by: Chris Zhong 
>> ---
>>  include/linux/extcon.h | 14 +-
>>  1 file changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/linux/extcon.h b/include/linux/extcon.h
>> index 9147c42..4411893 100644
>> --- a/include/linux/extcon.h
>> +++ b/include/linux/extcon.h
>> @@ -131,9 +131,21 @@
>>  #define EXTCON_PROP_JACK_MAX100
>>  #define EXTCON_PROP_JACK_CNT (EXTCON_PROP_JACK_MAX - EXTCON_PROP_JACK_MIN + 
>> 1)
>>  
>> +/*
>> + * Properties of EXTCON_TYPE_DISP.
>> + *
>> + * - EXTCON_PROP_DISP_HPD
> 
> You should add the full name of 'HPD'.

On previous mail, I replied ambiguous comment.

I mean that you better to add the property name with full name as following:

EXTCON_PROP_DISP_HPD ( Hxxx Pxxx Dxxx)

[snip]

-- 
Best Regards,
Chanwoo Choi

Re: [PATCH] extcon: Introduce EXTCON_PROP_DISP_HPD property

[Chanwoo Choi]

Hi Chris,

On 2016년 09월 12일 10:03, Chanwoo Choi wrote:
> Hi Chris,
> 
> On 2016년 09월 10일 09:33, Chris Zhong wrote:
>> EXTCON_PROP_DISP_HPD is need by display port, if the system has no hpd
>> interrupt, this property can be used.
> 
> What is meaning of HPD? So, you need to add the
> description and reference for HPD in commit message.
> 
> For example,
> When adding EXTCON_PROP_USB_SS property[1],
> the commit message included the reference for USB SuperSpeed.
> [1] 
> https://git.kernel.org/cgit/linux/kernel/git/chanwoo/extcon.git/commit/?h=extcon-next=8457a1b49a2af0a0e71f80afed9f7c80de361610
> 
>>
>> Change-Id: I8b3eb78429126eaa369b10711b7f857b0a3df8ed
> 
> You have to remove the 'Change-Id'.
> 
>> Signed-off-by: Chris Zhong 
>> ---
>>  include/linux/extcon.h | 14 +-
>>  1 file changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/include/linux/extcon.h b/include/linux/extcon.h
>> index 9147c42..4411893 100644
>> --- a/include/linux/extcon.h
>> +++ b/include/linux/extcon.h
>> @@ -131,9 +131,21 @@
>>  #define EXTCON_PROP_JACK_MAX100
>>  #define EXTCON_PROP_JACK_CNT (EXTCON_PROP_JACK_MAX - EXTCON_PROP_JACK_MIN + 
>> 1)
>>  
>> +/*
>> + * Properties of EXTCON_TYPE_DISP.
>> + *
>> + * - EXTCON_PROP_DISP_HPD
> 
> You should add the full name of 'HPD'.

On previous mail, I replied ambiguous comment.

I mean that you better to add the property name with full name as following:

EXTCON_PROP_DISP_HPD ( Hxxx Pxxx Dxxx)

[snip]

-- 
Best Regards,
Chanwoo Choi

RE: Kernel panic - encryption/decryption failed when open file on Arm64

[liushuoran]

Hi Ard,

Thanks for the prompt reply. With the patch, there is no panic anymore. But it 
seems that the encryption/decryption is not successful anyway.

As Herbert points out, "If the page allocation fails in blkcipher_walk_next 
it'll simply switch over to processing it block by block". So does that mean 
the encryption/decryption should be successful even if the page allocation 
fails? Please correct me if I misunderstand anything. Thanks in advance.

Regards,
Shuoran

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Friday, September 09, 2016 6:57 PM
> To: Xiakaixu
> Cc: Herbert Xu; David S. Miller; Theodore Ts'o; Jaegeuk Kim;
> nhor...@tuxdriver.com; m...@iki.fi; linux-cry...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Wangbintian; liushuoran; Huxinwei; zhangzhibin
> (C)
> Subject: Re: Kernel panic - encryption/decryption failed when open file on
> Arm64
> 
> On 9 September 2016 at 11:31, Ard Biesheuvel 
> wrote:
> > On 9 September 2016 at 11:19, xiakaixu  wrote:
> >> Hi,
> >>
> >> After a deeply research about this crash, seems it is a specific
> >> bug that only exists in armv8 board. And it occurs in this function
> >> in arch/arm64/crypto/aes-glue.c.
> >>
> >> static int ctr_encrypt(struct blkcipher_desc *desc, struct scatterlist 
> >> *dst,
> >>struct scatterlist *src, unsigned int nbytes)
> >> {
> >>...
> >>
> >> desc->flags &= ~CRYPTO_TFM_REQ_MAY_SLEEP;
> >> blkcipher_walk_init(, dst, src, nbytes);
> >> err = blkcipher_walk_virt_block(desc, , AES_BLOCK_SIZE);
> --->
> >> page allocation failed
> >>
> >> ...
> >>
> >> while ((blocks = (walk.nbytes / AES_BLOCK_SIZE)))
> {   >
> >> walk.nbytes = 0, and skip this loop
> >> aes_ctr_encrypt(walk.dst.virt.addr, walk.src.virt.addr,
> >> (u8 *)ctx->key_enc, rounds, blocks,
> walk.iv,
> >> first);
> >> ...
> >> err = blkcipher_walk_done(desc, ,
> >>   walk.nbytes %
> AES_BLOCK_SIZE);
> >> }
> >> if (nbytes)
> { >
> >> enter this if() statement
> >> u8 *tdst = walk.dst.virt.addr + blocks * AES_BLOCK_SIZE;
> >> u8 *tsrc = walk.src.virt.addr + blocks * AES_BLOCK_SIZE;
> >> ...
> >>
> >> aes_ctr_encrypt(tail, tsrc, (u8 *)ctx->key_enc, rounds,
> >> > the the sencond input parameter is NULL, so crash...
> >> blocks, walk.iv, first);
> >> ...
> >> }
> >> ...
> >> }
> >>
> >>
> >> If the page allocation failed in the function blkcipher_walk_virt_block(),
> >> the variable walk.nbytes = 0, so it will skip the while() loop and enter
> >> the if(nbytes) statment. But here the varibale tsrc is NULL and it is also
> >> the sencond input parameter of the function aes_ctr_encrypt()... Kernel
> >> Panic...
> >>
> >> I have also researched the similar function in other architectures, and
> >> there if(walk.nbytes) is used, not this if(nbytes) statement in the armv8.
> >> so I think this armv8 function ctr_encrypt() should deal with the page
> >> allocation failed situation.
> >>
> 
> Does this solve your problem?
> 
> diff --git a/arch/arm64/crypto/aes-glue.c b/arch/arm64/crypto/aes-glue.c
> index 5c888049d061..6b2aa0fd6cd0 100644
> --- a/arch/arm64/crypto/aes-glue.c
> +++ b/arch/arm64/crypto/aes-glue.c
> @@ -216,7 +216,7 @@ static int ctr_encrypt(struct blkcipher_desc
> *desc, struct scatterlist *dst,
> err = blkcipher_walk_done(desc, ,
>   walk.nbytes % AES_BLOCK_SIZE);
> }
> -   if (nbytes) {
> +   if (walk.nbytes % AES_BLOCK_SIZE) {
> u8 *tdst = walk.dst.virt.addr + blocks * AES_BLOCK_SIZE;
> u8 *tsrc = walk.src.virt.addr + blocks * AES_BLOCK_SIZE;
> u8 __aligned(8) tail[AES_BLOCK_SIZE];

RE: Kernel panic - encryption/decryption failed when open file on Arm64

[liushuoran]

Hi Ard,

Thanks for the prompt reply. With the patch, there is no panic anymore. But it 
seems that the encryption/decryption is not successful anyway.

As Herbert points out, "If the page allocation fails in blkcipher_walk_next 
it'll simply switch over to processing it block by block". So does that mean 
the encryption/decryption should be successful even if the page allocation 
fails? Please correct me if I misunderstand anything. Thanks in advance.

Regards,
Shuoran

> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Friday, September 09, 2016 6:57 PM
> To: Xiakaixu
> Cc: Herbert Xu; David S. Miller; Theodore Ts'o; Jaegeuk Kim;
> nhor...@tuxdriver.com; m...@iki.fi; linux-cry...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Wangbintian; liushuoran; Huxinwei; zhangzhibin
> (C)
> Subject: Re: Kernel panic - encryption/decryption failed when open file on
> Arm64
> 
> On 9 September 2016 at 11:31, Ard Biesheuvel 
> wrote:
> > On 9 September 2016 at 11:19, xiakaixu  wrote:
> >> Hi,
> >>
> >> After a deeply research about this crash, seems it is a specific
> >> bug that only exists in armv8 board. And it occurs in this function
> >> in arch/arm64/crypto/aes-glue.c.
> >>
> >> static int ctr_encrypt(struct blkcipher_desc *desc, struct scatterlist 
> >> *dst,
> >>struct scatterlist *src, unsigned int nbytes)
> >> {
> >>...
> >>
> >> desc->flags &= ~CRYPTO_TFM_REQ_MAY_SLEEP;
> >> blkcipher_walk_init(, dst, src, nbytes);
> >> err = blkcipher_walk_virt_block(desc, , AES_BLOCK_SIZE);
> --->
> >> page allocation failed
> >>
> >> ...
> >>
> >> while ((blocks = (walk.nbytes / AES_BLOCK_SIZE)))
> {   >
> >> walk.nbytes = 0, and skip this loop
> >> aes_ctr_encrypt(walk.dst.virt.addr, walk.src.virt.addr,
> >> (u8 *)ctx->key_enc, rounds, blocks,
> walk.iv,
> >> first);
> >> ...
> >> err = blkcipher_walk_done(desc, ,
> >>   walk.nbytes %
> AES_BLOCK_SIZE);
> >> }
> >> if (nbytes)
> { >
> >> enter this if() statement
> >> u8 *tdst = walk.dst.virt.addr + blocks * AES_BLOCK_SIZE;
> >> u8 *tsrc = walk.src.virt.addr + blocks * AES_BLOCK_SIZE;
> >> ...
> >>
> >> aes_ctr_encrypt(tail, tsrc, (u8 *)ctx->key_enc, rounds,
> >> > the the sencond input parameter is NULL, so crash...
> >> blocks, walk.iv, first);
> >> ...
> >> }
> >> ...
> >> }
> >>
> >>
> >> If the page allocation failed in the function blkcipher_walk_virt_block(),
> >> the variable walk.nbytes = 0, so it will skip the while() loop and enter
> >> the if(nbytes) statment. But here the varibale tsrc is NULL and it is also
> >> the sencond input parameter of the function aes_ctr_encrypt()... Kernel
> >> Panic...
> >>
> >> I have also researched the similar function in other architectures, and
> >> there if(walk.nbytes) is used, not this if(nbytes) statement in the armv8.
> >> so I think this armv8 function ctr_encrypt() should deal with the page
> >> allocation failed situation.
> >>
> 
> Does this solve your problem?
> 
> diff --git a/arch/arm64/crypto/aes-glue.c b/arch/arm64/crypto/aes-glue.c
> index 5c888049d061..6b2aa0fd6cd0 100644
> --- a/arch/arm64/crypto/aes-glue.c
> +++ b/arch/arm64/crypto/aes-glue.c
> @@ -216,7 +216,7 @@ static int ctr_encrypt(struct blkcipher_desc
> *desc, struct scatterlist *dst,
> err = blkcipher_walk_done(desc, ,
>   walk.nbytes % AES_BLOCK_SIZE);
> }
> -   if (nbytes) {
> +   if (walk.nbytes % AES_BLOCK_SIZE) {
> u8 *tdst = walk.dst.virt.addr + blocks * AES_BLOCK_SIZE;
> u8 *tsrc = walk.src.virt.addr + blocks * AES_BLOCK_SIZE;
> u8 __aligned(8) tail[AES_BLOCK_SIZE];

Re: [PATCH 4/4] clk: mediatek: Add MT6797 clock support

[Mars Cheng]

Hi Stephen

Thanks for your review. Response inlined.

On Thu, 2016-09-08 at 12:50 -0700, Stephen Boyd wrote:
> On 09/08/2016 03:49 AM, Mars Cheng wrote:
> > Add MT6797 clock support, include topckgen, apmixedsys,
> > infracfg and subsystem clocks.
> >
> > Signed-off-by: Mars Cheng 
> > ---
> >  arch/arm64/boot/dts/mediatek/mt6797.dtsi |   66 ++-
> 
> Please don't combine dts and clk driver changes together. We generally
> don't take dts changes through clk tree.

OK, will separate clk driver in single submit next time.

> 
> > diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
> > index 5aa6204..ce91ecb 100644
> > --- a/drivers/clk/mediatek/Kconfig
> > +++ b/drivers/clk/mediatek/Kconfig
> > @@ -56,6 +56,42 @@ config COMMON_CLK_MT2701_BDPSYS
> > ---help---
> >   This driver supports Mediatek MT2701 bdpsys clocks.
> >  
> 
> What tree is this based on?
Also 4.8-rc1, will base on clk-next to sent the patch.

> 
> > +config COMMON_CLK_MT6797
> > +   bool "Clock driver for Mediatek MT6797"
> > +   depends on COMMON_CLK
> 
> This sort of depends shouldn't be necessary.
> 

Got it. Will fix like this:
+config COMMON_CLK_MT6797
+   bool "Clock driver for Mediatek MT6797"
+   select COMMON_CLK_MEDIATEK
+   default ARCH_MEDIATEK
+   ---help---
+ This driver supports Mediatek MT6797 basic clocks.

> > +   select COMMON_CLK_MEDIATEK
> > +   default ARCH_MEDIATEK
> > +   ---help---
> > + This driver supports Mediatek MT6797 basic clocks.
> > +
> >
> >
> > diff --git a/drivers/clk/mediatek/clk-mt6797-img.c 
> > b/drivers/clk/mediatek/clk-mt6797-img.c
> > new file mode 100644
> > index 000..4ecd201
> > --- /dev/null
> > +++ b/drivers/clk/mediatek/clk-mt6797-img.c
> > @@ -0,0 +1,87 @@
> > +/* Copyright (c) 2016 MediaTek Inc.
> > + * Author: Kevin Chen 
> > + *
> > + * 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.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include 
> 
> clk-provider.h?

Sure. Will fix it.

> 
> > +#include 
> > +#include 
> > +
> > +#include "clk-mtk.h"
> > +#include "clk-gate.h"
> > +
> > +static const struct mtk_gate_regs img_cg_regs = {
> > +   .set_ofs = 0x0004,
> > +   .clr_ofs = 0x0008,
> > +   .sta_ofs = 0x,
> > +};
> > +
> > +#define GATE_IMG(_id, _name, _parent, _shift) {\
> > +   .id = _id,  \
> > +   .name = _name,  \
> > +   .parent_name = _parent, \
> > +   .regs = _cg_regs,   \
> > +   .shift = _shift,\
> > +   .ops = _clk_gate_ops_setclr,\
> > +   }
> > +
> > +static const struct mtk_gate img_clks[] = {
> > +   GATE_IMG(CLK_IMG_FDVT, "img_fdvt", "mm_sel", 11),
> > +   GATE_IMG(CLK_IMG_DPE, "img_dpe", "mm_sel", 10),
> > +   GATE_IMG(CLK_IMG_DIP, "img_dip", "mm_sel", 6),
> > +   GATE_IMG(CLK_IMG_LARB6, "img_larb6", "mm_sel", 0),
> > +};
> > +
> > +static int mtk_imgsys_init(struct device *dev)
> > +{
> > +   struct clk_onecell_data *clk_data;
> > +   int r;
> > +
> > +   clk_data = mtk_alloc_clk_data(CLK_IMG_NR);
> > +   if (!clk_data) {
> > +   pr_err("%s: alloc failed\n", __func__);
> 
> Allocations already print a big error message so this is useless.

OK, will just return error code.

> 
> > +   goto alloc_err;
> > +   }
> > +
> > +   mtk_clk_register_gates(dev->of_node, img_clks, ARRAY_SIZE(img_clks),
> > +  clk_data);
> > +
> > +   r = of_clk_add_provider(dev->of_node, of_clk_src_onecell_get,
> > +   clk_data);
> > +   if (r)
> > +   pr_err("%s: could not register clock provider: %d\n",
> > +  __func__, r);
> > +
> > +   return r;
> > +
> > +alloc_err:
> > +   return -ENOMEM;
> > +}
> > +
> > +static const struct of_device_id of_match_clk_mt6797_img[] = {
> > +   { .compatible = "mediatek,mt6797-imgsys", },
> > +   {}
> > +};
> > +
> > +static int clk_mt6797_img_probe(struct platform_device *pdev)
> > +{
> > +   return mtk_imgsys_init(>dev);
> > +}
> > +
> > +static struct platform_driver clk_mt6797_img_drv = {
> > +   .probe = clk_mt6797_img_probe,
> > +   .driver = {
> > +   .name = "clk-mt6797-img",
> > +   .of_match_table = of_match_clk_mt6797_img,
> > +   },
> > +};
> > +
> > +builtin_platform_driver(clk_mt6797_img_drv);
> > diff --git a/drivers/clk/mediatek/clk-mt6797-mm.c 
> > b/drivers/clk/mediatek/clk-mt6797-mm.c
> > new file mode 100644
> > index 000..77f0342
> > --- /dev/null
> > +++ 

Re: [PATCH 4/4] clk: mediatek: Add MT6797 clock support

[Mars Cheng]

Hi Stephen

Thanks for your review. Response inlined.

On Thu, 2016-09-08 at 12:50 -0700, Stephen Boyd wrote:
> On 09/08/2016 03:49 AM, Mars Cheng wrote:
> > Add MT6797 clock support, include topckgen, apmixedsys,
> > infracfg and subsystem clocks.
> >
> > Signed-off-by: Mars Cheng 
> > ---
> >  arch/arm64/boot/dts/mediatek/mt6797.dtsi |   66 ++-
> 
> Please don't combine dts and clk driver changes together. We generally
> don't take dts changes through clk tree.

OK, will separate clk driver in single submit next time.

> 
> > diff --git a/drivers/clk/mediatek/Kconfig b/drivers/clk/mediatek/Kconfig
> > index 5aa6204..ce91ecb 100644
> > --- a/drivers/clk/mediatek/Kconfig
> > +++ b/drivers/clk/mediatek/Kconfig
> > @@ -56,6 +56,42 @@ config COMMON_CLK_MT2701_BDPSYS
> > ---help---
> >   This driver supports Mediatek MT2701 bdpsys clocks.
> >  
> 
> What tree is this based on?
Also 4.8-rc1, will base on clk-next to sent the patch.

> 
> > +config COMMON_CLK_MT6797
> > +   bool "Clock driver for Mediatek MT6797"
> > +   depends on COMMON_CLK
> 
> This sort of depends shouldn't be necessary.
> 

Got it. Will fix like this:
+config COMMON_CLK_MT6797
+   bool "Clock driver for Mediatek MT6797"
+   select COMMON_CLK_MEDIATEK
+   default ARCH_MEDIATEK
+   ---help---
+ This driver supports Mediatek MT6797 basic clocks.

> > +   select COMMON_CLK_MEDIATEK
> > +   default ARCH_MEDIATEK
> > +   ---help---
> > + This driver supports Mediatek MT6797 basic clocks.
> > +
> >
> >
> > diff --git a/drivers/clk/mediatek/clk-mt6797-img.c 
> > b/drivers/clk/mediatek/clk-mt6797-img.c
> > new file mode 100644
> > index 000..4ecd201
> > --- /dev/null
> > +++ b/drivers/clk/mediatek/clk-mt6797-img.c
> > @@ -0,0 +1,87 @@
> > +/* Copyright (c) 2016 MediaTek Inc.
> > + * Author: Kevin Chen 
> > + *
> > + * 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.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include 
> 
> clk-provider.h?

Sure. Will fix it.

> 
> > +#include 
> > +#include 
> > +
> > +#include "clk-mtk.h"
> > +#include "clk-gate.h"
> > +
> > +static const struct mtk_gate_regs img_cg_regs = {
> > +   .set_ofs = 0x0004,
> > +   .clr_ofs = 0x0008,
> > +   .sta_ofs = 0x,
> > +};
> > +
> > +#define GATE_IMG(_id, _name, _parent, _shift) {\
> > +   .id = _id,  \
> > +   .name = _name,  \
> > +   .parent_name = _parent, \
> > +   .regs = _cg_regs,   \
> > +   .shift = _shift,\
> > +   .ops = _clk_gate_ops_setclr,\
> > +   }
> > +
> > +static const struct mtk_gate img_clks[] = {
> > +   GATE_IMG(CLK_IMG_FDVT, "img_fdvt", "mm_sel", 11),
> > +   GATE_IMG(CLK_IMG_DPE, "img_dpe", "mm_sel", 10),
> > +   GATE_IMG(CLK_IMG_DIP, "img_dip", "mm_sel", 6),
> > +   GATE_IMG(CLK_IMG_LARB6, "img_larb6", "mm_sel", 0),
> > +};
> > +
> > +static int mtk_imgsys_init(struct device *dev)
> > +{
> > +   struct clk_onecell_data *clk_data;
> > +   int r;
> > +
> > +   clk_data = mtk_alloc_clk_data(CLK_IMG_NR);
> > +   if (!clk_data) {
> > +   pr_err("%s: alloc failed\n", __func__);
> 
> Allocations already print a big error message so this is useless.

OK, will just return error code.

> 
> > +   goto alloc_err;
> > +   }
> > +
> > +   mtk_clk_register_gates(dev->of_node, img_clks, ARRAY_SIZE(img_clks),
> > +  clk_data);
> > +
> > +   r = of_clk_add_provider(dev->of_node, of_clk_src_onecell_get,
> > +   clk_data);
> > +   if (r)
> > +   pr_err("%s: could not register clock provider: %d\n",
> > +  __func__, r);
> > +
> > +   return r;
> > +
> > +alloc_err:
> > +   return -ENOMEM;
> > +}
> > +
> > +static const struct of_device_id of_match_clk_mt6797_img[] = {
> > +   { .compatible = "mediatek,mt6797-imgsys", },
> > +   {}
> > +};
> > +
> > +static int clk_mt6797_img_probe(struct platform_device *pdev)
> > +{
> > +   return mtk_imgsys_init(>dev);
> > +}
> > +
> > +static struct platform_driver clk_mt6797_img_drv = {
> > +   .probe = clk_mt6797_img_probe,
> > +   .driver = {
> > +   .name = "clk-mt6797-img",
> > +   .of_match_table = of_match_clk_mt6797_img,
> > +   },
> > +};
> > +
> > +builtin_platform_driver(clk_mt6797_img_drv);
> > diff --git a/drivers/clk/mediatek/clk-mt6797-mm.c 
> > b/drivers/clk/mediatek/clk-mt6797-mm.c
> > new file mode 100644
> > index 000..77f0342
> > --- /dev/null
> > +++ b/drivers/clk/mediatek/clk-mt6797-mm.c
> > @@ -0,0 

Re: [PATCH v2] extcon: Add support for qcom SPMI PMIC USB id detection hardware

[Chanwoo Choi]

Hi Stephen,

Looks good to me.
But, there are something that need to be modified.
- add the author information
- add the description of driver
- use the extcon_set_state() instead of extcon_set_cable_state_()

I modified this patch and applied it because I should send
the pull request within this week after releasing the rc6.

I added the comment about the modification.

On 2016년 09월 10일 06:48, Stephen Boyd wrote:
> Some Qualcomm PMICs have a misc device that performs USB id pin
> detection via an interrupt. When the interrupt triggers, we
> should read the interrupt line to see if it has gone high or low.
> If the interrupt is low then the ID pin is grounded, and if the
> interrupt is high then the ID pin is being held high.
> 
> Cc: Roger Quadros 
> Cc: Chanwoo Choi 
> Signed-off-by: Stephen Boyd 
> ---
> 
> Changes from v1:
>  * Fixed Makefile ordering
>  * Fixed up copyright markings
> 
>  .../bindings/extcon/qcom,pm8941-misc.txt   |  41 +
>  drivers/extcon/Kconfig |   6 +
>  drivers/extcon/Makefile|   1 +
>  drivers/extcon/extcon-qcom-spmi-misc.c | 167 
> +
>  4 files changed, 215 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.txt
>  create mode 100644 drivers/extcon/extcon-qcom-spmi-misc.c
> 
> diff --git a/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.txt 
> b/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.txt
> new file mode 100644
> index ..35383adb10f1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.txt
> @@ -0,0 +1,41 @@
> +Qualcomm's PM8941 USB ID Extcon device
> +
> +Some Qualcomm PMICs have a "misc" module that can be used to detect when
> +the USB ID pin has been pulled low or high.
> +
> +PROPERTIES
> +
> +- compatible:
> +Usage: required
> +Value type: 
> +Definition: Should contain "qcom,pm8941-misc";
> +
> +- reg:
> +Usage: required
> +Value type: 
> +Definition: Should contain the offset to the misc address space
> +
> +- interrupts:
> +Usage: required
> +Value type: 
> +Definition: Should contain the usb id interrupt
> +
> +- interrupt-names:
> +Usage: required
> +Value type: 
> +Definition: Should contain the string "usb_id" for the usb id interrupt
> +
> +Example:
> +
> + pmic {
> + usb_id: misc@900 {
> + compatible = "qcom,pm8941-misc";
> + reg = <0x900>;
> + interrupts = <0x0 0x9 0 IRQ_TYPE_EDGE_BOTH>;
> + interrupt-names = "usb_id";
> + };
> + }
> +
> + usb-controller {
> + extcon = <_id>;
> + };
> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
> index 3d89e60a3e71..04788d92ea52 100644
> --- a/drivers/extcon/Kconfig
> +++ b/drivers/extcon/Kconfig
> @@ -96,6 +96,12 @@ config EXTCON_PALMAS
> Say Y here to enable support for USB peripheral and USB host
> detection by palmas usb.
>  
> +config EXTCON_QCOM_SPMI_MISC
> + tristate "Qualcomm USB extcon support"
> + help
> +   Say Y here to enable SPMI PMIC based USB cable detection
> +   support on Qualcomm PMICs such as PM8941.
> +
>  config EXTCON_RT8973A
>   tristate "Richtek RT8973A EXTCON support"
>   depends on I2C
> diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
> index 972c813c375b..31a0a999c4fb 100644
> --- a/drivers/extcon/Makefile
> +++ b/drivers/extcon/Makefile
> @@ -14,6 +14,7 @@ obj-$(CONFIG_EXTCON_MAX77693)   += extcon-max77693.o
>  obj-$(CONFIG_EXTCON_MAX77843)+= extcon-max77843.o
>  obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
>  obj-$(CONFIG_EXTCON_PALMAS)  += extcon-palmas.o
> +obj-$(CONFIG_EXTCON_QCOM_SPMI_MISC) += extcon-qcom-spmi-misc.o
>  obj-$(CONFIG_EXTCON_RT8973A) += extcon-rt8973a.o
>  obj-$(CONFIG_EXTCON_SM5502)  += extcon-sm5502.o
>  obj-$(CONFIG_EXTCON_USB_GPIO)+= extcon-usb-gpio.o
> diff --git a/drivers/extcon/extcon-qcom-spmi-misc.c 
> b/drivers/extcon/extcon-qcom-spmi-misc.c
> new file mode 100644
> index ..1b8e24494c60
> --- /dev/null
> +++ b/drivers/extcon/extcon-qcom-spmi-misc.c
> @@ -0,0 +1,167 @@
> +/**
> + * Based on extcon-usb-gpio.c

I think that following description is better than before.
I'll modify it.

  * extcon-qcom-spmi-misc.c - Qualcomm USB extcon driver to support USB ID
  * detection based on extcon-usb-gpio.c.

> + *
> + * Copyright (C) 2016 Linaro Ltd

s/Ltd/Ltd.

You are missing the author information. I'll add following information:
* Stephen Boyd 

> + *
> + * 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.
> + *
> + * This 

Re: [PATCH v2] extcon: Add support for qcom SPMI PMIC USB id detection hardware

[Chanwoo Choi]

Hi Stephen,

Looks good to me.
But, there are something that need to be modified.
- add the author information
- add the description of driver
- use the extcon_set_state() instead of extcon_set_cable_state_()

I modified this patch and applied it because I should send
the pull request within this week after releasing the rc6.

I added the comment about the modification.

On 2016년 09월 10일 06:48, Stephen Boyd wrote:
> Some Qualcomm PMICs have a misc device that performs USB id pin
> detection via an interrupt. When the interrupt triggers, we
> should read the interrupt line to see if it has gone high or low.
> If the interrupt is low then the ID pin is grounded, and if the
> interrupt is high then the ID pin is being held high.
> 
> Cc: Roger Quadros 
> Cc: Chanwoo Choi 
> Signed-off-by: Stephen Boyd 
> ---
> 
> Changes from v1:
>  * Fixed Makefile ordering
>  * Fixed up copyright markings
> 
>  .../bindings/extcon/qcom,pm8941-misc.txt   |  41 +
>  drivers/extcon/Kconfig |   6 +
>  drivers/extcon/Makefile|   1 +
>  drivers/extcon/extcon-qcom-spmi-misc.c | 167 
> +
>  4 files changed, 215 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.txt
>  create mode 100644 drivers/extcon/extcon-qcom-spmi-misc.c
> 
> diff --git a/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.txt 
> b/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.txt
> new file mode 100644
> index ..35383adb10f1
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/extcon/qcom,pm8941-misc.txt
> @@ -0,0 +1,41 @@
> +Qualcomm's PM8941 USB ID Extcon device
> +
> +Some Qualcomm PMICs have a "misc" module that can be used to detect when
> +the USB ID pin has been pulled low or high.
> +
> +PROPERTIES
> +
> +- compatible:
> +Usage: required
> +Value type: 
> +Definition: Should contain "qcom,pm8941-misc";
> +
> +- reg:
> +Usage: required
> +Value type: 
> +Definition: Should contain the offset to the misc address space
> +
> +- interrupts:
> +Usage: required
> +Value type: 
> +Definition: Should contain the usb id interrupt
> +
> +- interrupt-names:
> +Usage: required
> +Value type: 
> +Definition: Should contain the string "usb_id" for the usb id interrupt
> +
> +Example:
> +
> + pmic {
> + usb_id: misc@900 {
> + compatible = "qcom,pm8941-misc";
> + reg = <0x900>;
> + interrupts = <0x0 0x9 0 IRQ_TYPE_EDGE_BOTH>;
> + interrupt-names = "usb_id";
> + };
> + }
> +
> + usb-controller {
> + extcon = <_id>;
> + };
> diff --git a/drivers/extcon/Kconfig b/drivers/extcon/Kconfig
> index 3d89e60a3e71..04788d92ea52 100644
> --- a/drivers/extcon/Kconfig
> +++ b/drivers/extcon/Kconfig
> @@ -96,6 +96,12 @@ config EXTCON_PALMAS
> Say Y here to enable support for USB peripheral and USB host
> detection by palmas usb.
>  
> +config EXTCON_QCOM_SPMI_MISC
> + tristate "Qualcomm USB extcon support"
> + help
> +   Say Y here to enable SPMI PMIC based USB cable detection
> +   support on Qualcomm PMICs such as PM8941.
> +
>  config EXTCON_RT8973A
>   tristate "Richtek RT8973A EXTCON support"
>   depends on I2C
> diff --git a/drivers/extcon/Makefile b/drivers/extcon/Makefile
> index 972c813c375b..31a0a999c4fb 100644
> --- a/drivers/extcon/Makefile
> +++ b/drivers/extcon/Makefile
> @@ -14,6 +14,7 @@ obj-$(CONFIG_EXTCON_MAX77693)   += extcon-max77693.o
>  obj-$(CONFIG_EXTCON_MAX77843)+= extcon-max77843.o
>  obj-$(CONFIG_EXTCON_MAX8997) += extcon-max8997.o
>  obj-$(CONFIG_EXTCON_PALMAS)  += extcon-palmas.o
> +obj-$(CONFIG_EXTCON_QCOM_SPMI_MISC) += extcon-qcom-spmi-misc.o
>  obj-$(CONFIG_EXTCON_RT8973A) += extcon-rt8973a.o
>  obj-$(CONFIG_EXTCON_SM5502)  += extcon-sm5502.o
>  obj-$(CONFIG_EXTCON_USB_GPIO)+= extcon-usb-gpio.o
> diff --git a/drivers/extcon/extcon-qcom-spmi-misc.c 
> b/drivers/extcon/extcon-qcom-spmi-misc.c
> new file mode 100644
> index ..1b8e24494c60
> --- /dev/null
> +++ b/drivers/extcon/extcon-qcom-spmi-misc.c
> @@ -0,0 +1,167 @@
> +/**
> + * Based on extcon-usb-gpio.c

I think that following description is better than before.
I'll modify it.

  * extcon-qcom-spmi-misc.c - Qualcomm USB extcon driver to support USB ID
  * detection based on extcon-usb-gpio.c.

> + *
> + * Copyright (C) 2016 Linaro Ltd

s/Ltd/Ltd.

You are missing the author information. I'll add following information:
* Stephen Boyd 

> + *
> + * 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.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; 

Re: [PATCH] pinctrl: ret needs to be an int for -ve return value from regmap_update_bits

[Andrew Jeffery]

On Sun, 2016-09-11 at 09:36 +0100, Colin King wrote:
> From: Colin Ian King 
> 
> Macro regmap_update_bits can return a -ve on an error value so ret
> needs to be an integer rather than a bool type.
> 
> Fixes warning found by static analysis with cppcheck:
> [drivers/pinctrl/aspeed/pinctrl-aspeed.c:192]: (warning) Comparison of
>   a boolean expression with an integer other than 0 or 1.
> 
> Signed-off-by: Colin Ian King 

Thanks Colin. Arnd independently discovered this bug and Joel and I
have CC'ed you on our responses there - the intent is to take Arnd's
patch.

Cheers,

Andrew

> ---
>  drivers/pinctrl/aspeed/pinctrl-aspeed.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed.c 
> b/drivers/pinctrl/aspeed/pinctrl-aspeed.c
> index 7d461fc..75935ab 100644
> --- a/drivers/pinctrl/aspeed/pinctrl-aspeed.c
> +++ b/drivers/pinctrl/aspeed/pinctrl-aspeed.c
> @@ -166,7 +166,7 @@ static bool aspeed_sig_expr_set(const struct 
> aspeed_sig_expr *expr,
>   bool enable, struct regmap *map)
>  {
>   int i;
> - bool ret;
> + int ret;
>  
>   ret = aspeed_sig_expr_eval(expr, enable, map);
>   if (ret)

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

Re: [PATCH] pinctrl: ret needs to be an int for -ve return value from regmap_update_bits

[Andrew Jeffery]

On Sun, 2016-09-11 at 09:36 +0100, Colin King wrote:
> From: Colin Ian King 
> 
> Macro regmap_update_bits can return a -ve on an error value so ret
> needs to be an integer rather than a bool type.
> 
> Fixes warning found by static analysis with cppcheck:
> [drivers/pinctrl/aspeed/pinctrl-aspeed.c:192]: (warning) Comparison of
>   a boolean expression with an integer other than 0 or 1.
> 
> Signed-off-by: Colin Ian King 

Thanks Colin. Arnd independently discovered this bug and Joel and I
have CC'ed you on our responses there - the intent is to take Arnd's
patch.

Cheers,

Andrew

> ---
>  drivers/pinctrl/aspeed/pinctrl-aspeed.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed.c 
> b/drivers/pinctrl/aspeed/pinctrl-aspeed.c
> index 7d461fc..75935ab 100644
> --- a/drivers/pinctrl/aspeed/pinctrl-aspeed.c
> +++ b/drivers/pinctrl/aspeed/pinctrl-aspeed.c
> @@ -166,7 +166,7 @@ static bool aspeed_sig_expr_set(const struct 
> aspeed_sig_expr *expr,
>   bool enable, struct regmap *map)
>  {
>   int i;
> - bool ret;
> + int ret;
>  
>   ret = aspeed_sig_expr_eval(expr, enable, map);
>   if (ret)

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

Re: [PATCH] logfs: remove from tree

[Dave Chinner]

On Sun, Sep 11, 2016 at 03:04:22PM +0200, Christoph Hellwig wrote:
> Logfs was introduced to the kernel in 2009, and hasn't seen any non
> drive-by changes since 2012, while having lots of unsolved issues
> including the complete lack of error handling, with more and more
> issues popping up without any fixes.
> 
> The logfs.org domain has been bouncing from a mail, and the maintainer
> on the non-logfs.org domain hasn't repsonded to past queries either.
> 
> Signed-off-by: Christoph Hellwig 
> ---
>  Documentation/filesystems/00-INDEX  |2 -
>  Documentation/filesystems/logfs.txt |  241 
>  MAINTAINERS |8 -
>  fs/Kconfig  |1 -
>  fs/Makefile |1 -
>  fs/logfs/Kconfig|   17 -
>  fs/logfs/Makefile   |   13 -
>  fs/logfs/compr.c|   95 --
>  fs/logfs/dev_bdev.c |  322 -
>  fs/logfs/dev_mtd.c  |  274 -
>  fs/logfs/dir.c  |  797 
>  fs/logfs/file.c |  285 -
>  fs/logfs/gc.c   |  732 ---
>  fs/logfs/inode.c|  428 ---
>  fs/logfs/journal.c  |  894 --
>  fs/logfs/logfs.h|  735 ---
>  fs/logfs/logfs_abi.h|  629 --
>  fs/logfs/readwrite.c| 2298 
> ---
>  fs/logfs/segment.c  |  961 ---
>  fs/logfs/super.c|  653 --

Wasn't the lib/btree.c implementation introduced with and only used
by logfs? Should that go as well?

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: [PATCH] logfs: remove from tree

[Dave Chinner]

On Sun, Sep 11, 2016 at 03:04:22PM +0200, Christoph Hellwig wrote:
> Logfs was introduced to the kernel in 2009, and hasn't seen any non
> drive-by changes since 2012, while having lots of unsolved issues
> including the complete lack of error handling, with more and more
> issues popping up without any fixes.
> 
> The logfs.org domain has been bouncing from a mail, and the maintainer
> on the non-logfs.org domain hasn't repsonded to past queries either.
> 
> Signed-off-by: Christoph Hellwig 
> ---
>  Documentation/filesystems/00-INDEX  |2 -
>  Documentation/filesystems/logfs.txt |  241 
>  MAINTAINERS |8 -
>  fs/Kconfig  |1 -
>  fs/Makefile |1 -
>  fs/logfs/Kconfig|   17 -
>  fs/logfs/Makefile   |   13 -
>  fs/logfs/compr.c|   95 --
>  fs/logfs/dev_bdev.c |  322 -
>  fs/logfs/dev_mtd.c  |  274 -
>  fs/logfs/dir.c  |  797 
>  fs/logfs/file.c |  285 -
>  fs/logfs/gc.c   |  732 ---
>  fs/logfs/inode.c|  428 ---
>  fs/logfs/journal.c  |  894 --
>  fs/logfs/logfs.h|  735 ---
>  fs/logfs/logfs_abi.h|  629 --
>  fs/logfs/readwrite.c| 2298 
> ---
>  fs/logfs/segment.c  |  961 ---
>  fs/logfs/super.c|  653 --

Wasn't the lib/btree.c implementation introduced with and only used
by logfs? Should that go as well?

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: [PATCH] pinctrl: aspeed: fix regmap error handling

[Andrew Jeffery]

On Mon, 2016-09-12 at 10:52 +0930, Joel Stanley wrote:
> On Fri, Sep 9, 2016 at 6:56 PM, Arnd Bergmann  wrote:
> > 
> > The newly added aspeed driver tries to check for a negative return
> > value from a pinctrl function, but stores the intermediate value in
> > a 'bool' variable, which cannot work:
> > 
> > drivers/pinctrl/aspeed/pinctrl-aspeed.c: In function 'aspeed_sig_expr_set':
> > drivers/pinctrl/aspeed/pinctrl-aspeed.c:192:11: error: comparison of 
> > constant '0' with boolean expression is always false [-Werror=bool-compare]
> > 
> > This slightly reworks the logic to use an explicit comparison with zero
> > before assigning to the temporary variable.
> Thanks for finding this Arnd.
> 
> Colin also found the issue. Thanks Colin!
> 
> I think we should take this version of the fix. Linus, can you put
> this in your tree please?

+1 on each point above.

I made a change to the loop body in response to feedback in one of the
earlier iterations and unfortunately this looks to have slipped past
me. I will look at adding a bit more static analysis to my patch
submission checklist!

> 
> > 
> > Signed-off-by: Arnd Bergmann 
> Acked-by: Joel Stanley 

Reviewed-by: Andrew Jeffery 

> 
> Cheers,
> 
> Joel
> 
> > 
> > ---
> >  drivers/pinctrl/aspeed/pinctrl-aspeed.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed.c 
> > b/drivers/pinctrl/aspeed/pinctrl-aspeed.c
> > index 7d461fc30d3c..0391f9f13f3e 100644
> > --- a/drivers/pinctrl/aspeed/pinctrl-aspeed.c
> > +++ b/drivers/pinctrl/aspeed/pinctrl-aspeed.c
> > @@ -187,10 +187,10 @@ static bool aspeed_sig_expr_set(const struct 
> > aspeed_sig_expr *expr,
> > continue;
> > 
> > ret = regmap_update_bits(map, desc->reg, desc->mask,
> > -   pattern << __ffs(desc->mask));
> > +   pattern << __ffs(desc->mask)) == 0;
> > 
> > -   if (ret < 0)
> > -   return false;
> > +   if (!ret)
> > +   return ret;
> > }
> > 
> > return aspeed_sig_expr_eval(expr, enable, map);
> > --
> > 2.9.0
> > 

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

Re: [PATCH] pinctrl: aspeed: fix regmap error handling

[Andrew Jeffery]

On Mon, 2016-09-12 at 10:52 +0930, Joel Stanley wrote:
> On Fri, Sep 9, 2016 at 6:56 PM, Arnd Bergmann  wrote:
> > 
> > The newly added aspeed driver tries to check for a negative return
> > value from a pinctrl function, but stores the intermediate value in
> > a 'bool' variable, which cannot work:
> > 
> > drivers/pinctrl/aspeed/pinctrl-aspeed.c: In function 'aspeed_sig_expr_set':
> > drivers/pinctrl/aspeed/pinctrl-aspeed.c:192:11: error: comparison of 
> > constant '0' with boolean expression is always false [-Werror=bool-compare]
> > 
> > This slightly reworks the logic to use an explicit comparison with zero
> > before assigning to the temporary variable.
> Thanks for finding this Arnd.
> 
> Colin also found the issue. Thanks Colin!
> 
> I think we should take this version of the fix. Linus, can you put
> this in your tree please?

+1 on each point above.

I made a change to the loop body in response to feedback in one of the
earlier iterations and unfortunately this looks to have slipped past
me. I will look at adding a bit more static analysis to my patch
submission checklist!

> 
> > 
> > Signed-off-by: Arnd Bergmann 
> Acked-by: Joel Stanley 

Reviewed-by: Andrew Jeffery 

> 
> Cheers,
> 
> Joel
> 
> > 
> > ---
> >  drivers/pinctrl/aspeed/pinctrl-aspeed.c | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/pinctrl/aspeed/pinctrl-aspeed.c 
> > b/drivers/pinctrl/aspeed/pinctrl-aspeed.c
> > index 7d461fc30d3c..0391f9f13f3e 100644
> > --- a/drivers/pinctrl/aspeed/pinctrl-aspeed.c
> > +++ b/drivers/pinctrl/aspeed/pinctrl-aspeed.c
> > @@ -187,10 +187,10 @@ static bool aspeed_sig_expr_set(const struct 
> > aspeed_sig_expr *expr,
> > continue;
> > 
> > ret = regmap_update_bits(map, desc->reg, desc->mask,
> > -   pattern << __ffs(desc->mask));
> > +   pattern << __ffs(desc->mask)) == 0;
> > 
> > -   if (ret < 0)
> > -   return false;
> > +   if (!ret)
> > +   return ret;
> > }
> > 
> > return aspeed_sig_expr_eval(expr, enable, map);
> > --
> > 2.9.0
> > 

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